I think that this book can clearly be labeled as an "oldie but a goodie". Published in 2004, this book provides a neat perspective on software development. This book was a great read providing good tips and thoughts on a large variety of topics. I particularly liked his articles on the microeconomics of software development. If you want to become good a designing products, then you have to understand what "designs" sell. I know that some software developers out there would say that that is more of a job for BA's or project managers. I disagree. Life is all about the value you can add to your job. Let me break into a story.
I was on the way to Toronto over Christmas, and was looking for a place to park in the Calgary international economy parking lot. There were none. I quickly hopped over to the park and jet. I got on the shuttle to the airport to find just myself and the bus driver. He was complaining about how the park and jet that he worked for never gave raises at all. He said that he had been working there for a few years and never once received a raise at all. At the time, I politely said that that was an unfortunate circumstance, and went on my way. But it really got me thinking. Why do people automatically assume that they should get raises? In my mind, everyone should get a cost of living increase. I don't think that you should get paid less the next year for doing the same job (unless of course you have been demoted). But why do people automatically think they deserve raises? What value have you added to your organization to deem such a raise necessary? Have you taken courses to increase your technology profile? Have you contributed above and beyond your job description?
How this relates back to the book is that a lot of what he talks about in the book has nothing to do with traditional software development. But keeping the topics in mind will help you add value to your job, and thus (hopefully) get you that raise. I think that good managers can spot the difference between good and bad programmers. I really feel that when you do your job properly, when you keep the big picture in mind, you do produce better programs, a better product, and a better customer experience.
If I had to summarize his book, I'd probably give the following points.
1) The Joel Test
http://joelonsoftware.com/articles/fog0000000043.html
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quite working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
The Joel test (as mentioned in the article) can be a quick guide to see where your software development practices are. You can also use it to rate places to work. You won't believe how many "15 year experience developers" who have never used source control. Even myself, I have only really used subversion up until this point and have not really gotten into the world of DVCS (mostly because my employer uses subversion.,. could be worse.. could be the visual source-safe).
2) Specs
This is a disease that you need to get. If you don't have it, infect yourself today!
http://www.joelonsoftware.com/articles/fog0000000036.html
3) Strategy letters
Basically interesting articles on how to build software that will sell, and a little insight into why some big companies do what they do.
All in all, this book was a really good read. It was good to read a book on software that wasn't exactly about the software that we write, but more about why we write it. (And a little about how to write it too!)
No comments:
Post a Comment