Improving the world with software
Better software. Better questions.
Essays on software development, teams and the craft of building things that last.
Essays, page 22
314 essays in the archive
-
Simple estimations work. Use the data you have available
I very often hear the “estimations” conversation. People are so infatuated with the estimations that they forget to look at the actual data. By data I mean what they have been able to accomplish in the past. When we were lost in the dark ages of Waterfall and it’s Linear Pseudo-iterative friends (like RUP) we …
-
The law of immediate action on productivity
In Software as in other activities quantity is not a synonym with quality. Here’s what I mean:It is very common for people to think that if they find a lot of bugs in a software before it is released that they know more about the quality level of their software. Normally that requires that you …
-
Agile is changing, is “Lean” the next word?
Kallokian seems to think so, even if he does use the “lean” word. Which is probably good, taking into account the “post-agilism” discussion ongoing now 🙂 Here it is, another article I wish I had written.
-
In the beginning there was the waterfall…
This is a post I whish I had written. Congrats Dave. Definitely worth a reading for anyone considering themselves agile practitioners.
-
The Software Engineering Institute (SEI) does it again…
The Software Engineering Institute gave us CMMI, but they haven’t stopped “helping” the software industry. Their report on “Documenting Software Architectures in an Agile World“(PDF alert) tries to define the difference between Agile-prone and Architecture-prone software projects. They tell us that agile requires you not to document architecture (I did not know that…), and later …
-
The different values of software features, 9 different examples
A few days ago I posted an entry about the different layers of value in a software feature. Today I ran into an excellent example of the differences between a system that focuses on what I called immediate value (Mac OS X) and another that clearly focuses on what I called expert value. Take a …
-
Quality is not just being “bug-free”, it is being “valuable”
The value of a software feature/product can be divided into 4 layers. When you code a feature you probably think immediately about the “technical value”, i.e. the technological improvement/innovation you are about to implement or algorithm/method. But it does not stop there. The expert user will find in it “expert value”, this is what a …
-
Simple software is not simplistic software! Joel and Norman are wrong
Joel and Norman state several things regarding simplicity in their respective blog, but what they say can be summarized in a simple syllogism (pun intended): People like the products with more features All products with more features have more controls in the User Interfacea are less simple Therefore: People want products that are less simple …
-
Is Apple the new “geek”?
As I type this blog entry in my new MacBook Pro, I’m thinking that Mac is the new “geek”.Apple products have become more and more attractive to those of us that have worked or played with computers since a young age. It’s no longer only for the Advertising/Design or Publishing industry. Macs are getting affordable …
-
Egineering truths, how to make better engineering decisions
Often in an engineering problem software developers tend to try and find the perfect solution and quickly fall in love with one idea that may work or then shoot down ideas that could work but not in all hypothetical circumstances (even if they are realistically not possible). Many discussions I’ve attended could have been cut …
-
Big Design Upfront = Design-in-progress = Less Productivity = Lost Money
Henrik Mårtenson has an excellent post on Design-in-progress (similar to work-in-progress in Lean Manufacturint). Really worth a read!
-
You cannot inspect quality into a document!
Inspections are a failed analogy.SEI writes in the page about software inspection: Software inspections provide value in improving reliability, availability, and maintainability. They don’t mention however that inspections improve reliability, availability and maintainability of the inspected artifact. In most software companies the inspected artifacts are: documents. This means that instead of improving the software itself …
Nothing matches that yet.
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.