I read this book not quite a year ago, but let a friend borrow it before I blogged about it. There is a good story behind why I have it as well. The author is a friend of mine from the old days. Luke went to Michigan for college while I graduated from Texas. When they met in the Rose Bowl last year, we made a “governor’s bet”—if his team won I’d have to ship him some Texas BBQ, if mine did he was sending me California wine. As we all know, Texas was victorious and Luke was on the hook for some hooch! When he paid up, he included his latest book along with two bottles of wine. Good guy, that Luke!
This is a really good reference for anyone in the software business. The author covers everything from product naming to when to start over and rewrite the whole thing. Developers will receive an understanding of what the marketing folks do for a living, and non-technical people will get a peek into what it takes to actually write software. Everyone involved will start to understand how a software project should be managed as well, what questions to ask and when to ask them. The best part is that at the end of each chapter there is a summary and checklist of things your organization should be doing; this makes the book valuable not only as a one-time resource, but as something that can be used time and again.
One of the topics covered concerns technical debt. This is a concept I’ve been concerned with for a while at my current job, but didn’t have a solid term to define it. Technical debt is what a project collects when tasks are done “quick and dirty” instead of taking the time to think about the entire problem and solution. The effort that is needed to later fix the inevitable issues that arise from cutting corners are the interest payments on the debt. Virtually every decision that was made on one of my current projects for the past couple of years (before I joined, of course!) was made with speed in mind, and now the product is in such bad shape that it is difficult to make any sort of change at all with any degree of quality. I’ve been railing about this at the office, and Hohmann’s words have helped bolster my case.
The foundation of a winning solution lies in the architecture that creates and sustains it.
No comments:
Post a Comment