Joel recently posted The Duct Tape Programmer which has received an enormous amount of buzz, both positive and negative. At work, I received emails telling me that the article is a must read, while receiving different emails flaming Joel. If you haven’t read it, I highly encourage you to do so. In short, it is about shipping software above all else.
I have spent the evening catching up on blogs, many of which are just responses to Joel’s, so I felt I should jump on the bandwagon. Instead of writing only my own sentiments, I have included a couple other thoughts from different bloggers to help clarify everything.
Uncle Bob really helped clarify the sentiments of developers.
Now don’t get me wrong. I’m the “Clean Code” guy. I want your code clean. I don’t want you making a mess. On the other hand, I want you to ship. I don’t want you gilding the lilly. I don’t want you wrapped up in endless polishing. I want you to ship, but I don’t want you to ship shit. If you think I’m contradicting myself, you’re wrong. There is no contradiction in the notion that you must ship, and that you must be proud of what you ship. The programmer who spends weeks building the perfect structure does just as much harm to the project as the programmer who hacks a bunch of crap together. Neither have struck the balance that’s required. In short, it’s bad to use too much duct tape. But I’d be suspicious if I didn’t see some duct tape!
While Casey Charlton explains the disconnect between the business and the developer.
Developers and business owners are not aligned in their goals - we prioritise the three factors [time, scope, quality] very differently, and for different reasons. Only two things can happen here, your developers need to align with their business objectives, or the business needs to align with the developers - or they can both compromise. Agile is all about the compromise, making both sides aware of the issues involved, and then coming to an agreement, but fundamentally - it is STILL A BUSINESS DECISION. While it is the responsibility of a professional developer to explain all the problems they see with low quality code, and to make their boss aware of all the potential future issues this may cause, it is also their professional responsibility to go with the decision their boss makes.
As for what I think, it is pretty simple. Shipping software and shipping quality software should be synonymous. It boils down to having great developers capable of great things. Writing tests that speed the team up, not down. Developing architectures that make sense now, not in 30 years. And finally, capable of releasing great software by the deadline.