“Recognizing the need is the primary condition for design.” — Charles Eames
Today I want to ask this question: Do the best developers follow, and prefer teams that follow, best practices? Or do the best developers build and ship fast, without regard to niceties, like unit tests and overall design?
Joel Spolsky wrote in praise of the duct tape programmer. This is the developer who cares only about shipping the product. This developer doesn’t write many unit tests unless the pace is leisurely because the customer doesn’t care about them. The duct tape programmer avoids complexity — understanding that any kind of complexity, anything that is hard for programmers to understand, will doom the project from the start.
Much as I enjoy Joel, we need to consider two ideas separately: shipping fast and avoiding complexity. Complexity is bad. Overly engineered projects are too hard to maintain. At the same time, we don’t want to ship it just once. I’ve worked with a few good duct tapers myself, and when they are working on a product that your customers are going to use, and pay for, year after year, shipping too quickly to do it right is the exception case. In the next sprint, they go pull off that duct tape and add some tests, refactoring as they go.
Unless you are working on a product that is short-lived, the business is going to require reliable and extensible code that can be evolved quickly. Pitting good practices against shipping fast is a false dichotomy.
Customers do care about unit tests — in fact they love them. Unit tests are like ABS brakes, you love them when they save you from an accident, even if you don’t know what they are. Customers know what bugs are, and they really hate them.
The symbiosis between the organization and the system’s architectural quality was identified in Big Ball of Mud. In some organizations, “swamp guides are more valuable than architects.” Engineers who value architectural best practices are not comfortable with permanently muddy architectures, or code that isn’t reliable. They intuitively understand the distinction between easy (familiar, fast) and simple (cleanly architected and modular). As Rich Hickey says, they don’t conflate simple with easy.
The answer to this question: Duct tape or architecture? Both, iteratively, as needed.