Last updated on 2014-09-07
“The Pragmatic Architect” is a column written by Frank Buschmann in the IEEE Software journal. It provides nice insights (although many of them with no scientific proof) on software development, architecture and other related subjects.
The March/April 2011 instance of this column named “Unusable Software is Useless, Part 2” talks about how developers must be “comfortable” with their code. I love this idea! If a developer cannot live with his code because it is too complex, or to abstract, or simply rotten, he will be hard driven to change it, even to make it better. Two main quotes from the article:
Key to developer habitability is the design of economic interfaces. Interfaces should contain those operations with a clear and meaningful purpose from a usage perspective, and they should focus on the minimal set of operations necessary to meet the components’ responsibility.
This sounds similar to what I wrote about in a previous post and called “Exact Interfaces”. And also very close to a quote I found a couple of days ago: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” (Antoine de Saint-Exupery, French writer, 1900 – 1944). So strive for perfection.
The second quote I really loved (and actually used when I was a team leader):
A less optimal but sufficient solution that a team can implement correctly is always better than a smart solution whose implementation requires skills not available in the team.
This point is very important since it has been shown that there is a big variance on the skills of software developers (I have a reference for this somewhere…), and many times you have one developer which is very very skilled and a bunch of developers which are fairly average (and some which are below this), and the smart guy comes up with a wonderful solution how to solve all of the problems of your systems… the only problem is that only he can implemented. So if you go with his idea you will have: a) Only one person who knows how the thing works; b) He will also become the bottleneck of the project; c) I he leaves, everything goes to hell. So going with an easier (and maybe less optimal) solution that the average programmer can implement is surely a better idea.
Be First to Comment