As software becomes more ubiquitous (I always wanted to use that word) software problems are also becoming ubiquitous. Related to my earlier post quoting an article on hacking automobile software, This article tells that GM has found problems in its car diagnostic software that requires fixing the software in about 60,000 cars. Nothing dramatic, but things are going from bad to worse very fast.
Welcome to the new world
A friend of mine gave me Rework
two weeks ago after a talk we had over my post on how finishing things helps you finish more, and how overwork starts creeping up on you and causes you to make mistakes (my friend was in one of those one-week deadlines, working 18 hours a day minimum and it was showing). The book is about how to do things in the modern internet-services economy. I think there are many lessons that can also be learned by other fields but not all of them are applicable (for example, in the internet you can have beta versions of a product and the customers will agree to this, but I don’t think I would like to have a beta dishwasher in my house, regardless of how much this can improve the final product).
Bottom line – EXCELLENT BOOK!. It has very short chapters, each having one thing to learn. They tell us that long-term planning is just a different name for guessing, and a good excuse for delaying decisions. Products should be shown to the world as soon as they are useful so that the customers can provide feedback. Things should be simple – if you do a simple thing and you do it right, why get complicated? being simple is not BAD. The bottom line of a business is not size nor number of products, but its efficiency (money per effort). You should have “alone time” to work without interruptions – without having meetings every other hour. And more and more stuff that you can take into practice to make your work, your product and your life better.
You can also go to the author’s site for more information on what they do and their “philosophy”. Great work guys!!!
So go ahead, buy this book from amazon.com
Object orientation has given us great things, but lately I have felt that we are having great problems managing the highly coupled components that OO has created. I regularly search the web when I need code that does something, but the problem is that the functionality comes wrapped inside class libraries with complex internal relations and other classes, most of which I usually don’t need, but have to learn and understand to use the class I want. And this is a waste off my time.
It made me very glad to see that I am not the only one who feels this way. OSGi Alliance Blog: What to Depend On, extends on this idea in a very clear way, much better than I can. Enjoy.
Just finished reading this great book about how to become a great software craftsman. While the comparison may be strange, this book is fairly similar to The Monk Who Sold His Ferrary – it shows you how to better yourself (one at software, the other in life), explains some paths (none of them scientific or proven) to achieve this goal and shows examples of how this worked out (this is where this book surpasses the monk, because it uses real-life quotes from real people).
All in all, Apprenticeship Patterns is a very enjoyable read that gets your mind thinking how to apply what it teaches. In the book’s conclusions I found a quote that explains once again in different wording why software development is so different from other engineering/scientific endeavours (page 114): “Software development is a craft precisely because we don’t understand it well enough to make it a codified discipline like science or engineering. Despite the best efforts… our field is still one where individual skill is often the most significant determining factor in a project’s success”. The book also provides loads of references that will make your reading list grow suddenly (it if doesn’t you’re either already a master or should find a job in another industry 
).
Support this work by purchasing this book from amazon
Just finished reading a nice article by Fank Buschmann, one of the authors of Pattern-Oriented Software Architecture called Unusable Software is Useless, Part 2.
The conclusion of the article gave words to a feeling I had when managing a software team a couple of years ago and my brightest programmer produced a brilliant solution to a problem we had in the system, only that he was the only person in the team who knew how to implement it correctly (worse yet, he was the only one that understood the solution excluding me). The problem was that he was to leave the team in a couple of months and this new “patch” would become a black box in the system. Buschmann states that “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” (emphasis mine).
Just another instance of the KISS principle in disguise.