This is part of my comment on HN.
At the right level of abstraction, DRY is the best advice possible. If you are building a data layer or a system, then you will be best off if you keep things DRY. However, once you get into product land. Then, I advise people to just get the job done quickly rather than worry about engineering principles.
The reason is very clear, in product land, engineering principles are third to usability and marketing. Avoiding DRY enables two things.
Polish
If you have five sections of code that are the same now, then there is good chance that they will diverge as the product matures. This is polish, and it is a good thing. While it is true that you have more work to do, it isn't rocket science. Trying to use DRY for polish is going to create even more cumbersome code with a lot of branches for all the special cases, and it tries to create an artificial problem of intelligence. Please avoid.
Hiring Scrubs
If you realize that the polish needed to make a product isn't exactly rocket science, then you can hire many scrubs. I define a scrub as someone new to computing, but capable enough to work within a developer environment to find and polish simple code. I like to hire scrubs as it provides a great first job in programming for many people. I was a scrub once, and it wasn't that bad as a 16 year-old.
Once you enable these two things, you have enabled marketing and the usability folks to iterate.
Update: Don't just hire scrubs
It takes a balancing act to get products out using a combination of awesome engineers, "good enough" engineers, and scrubs. A company ultimately needs all tiers to be able to push and iterate products quickly, and it is the company's job to ensure that the people process can nurture engineers from scrub to awesomeness.
I don't think I've seen a more ridiculous claim in a long time. Is it a practical joke, this far ahead of April Fools?
ReplyDeleteDRY is one of many practices that can help to improve code quality. I would hope that most programmers are trying to improve the quality of the products they produce not just chuck it out the door. The ultimate aim of all this is to deliver consistently and bring as much professionalism as we can to the craft of building software.
ReplyDeleteIf we just throw away these principles when its convenient then we might produce a result faster, but then we also accept the failures that occur. Over half of all software projects fail and until we accept that all programmers are rubbish at what they do we can't start to take good practices on.
As way of an example:- Surgeons resisted checklists for common surgeries for years, they still are resisting in the UK. Alas time and again mistakes were made, mistakes that a simple checklist would have stopped happening. Why did they resist a simple practice that statistically saved lives? Because they felt they didn't need such a simple crutch to do their jobs, they were an expert.
@Paul, @Charlie,
ReplyDeleteAlthough I probably would've avoided being quite so inflammatory as to saying to "avoid" DRY, I have to defend this post.
Design isn't just *about* compromise. Design *is* compromise. Even when there's only one profession involved. You cannot hold any one design principle as absolute, you always have to trade it off against other principles. If you've ever had to optimise a critical algorithm you may remember techniques like Loop Unrolling that deliberately introduce code repetition in order to eek out a little extra performance. DRY is sacrificed for performance. The same applies in a search index when you flatten or de-normalise your data in order to make it faster to query.
In a product development environment the most critical principle is often rapid delivery (so you can then adapt). Even if another design tenet is useful, like DRY, it often has to take second place or lower because of other constraints. I find DRY is more useful when the domain of the problem is well understood and the core problems are related to maintenance and encapsulation.
@Paul, you make a good point about adopting checklists. Doctors, midwives, and pilots use them with great success, but they're task based. If you can write a checklist that works for every type of software project then you will be a very rich man. It'd be like writing a checklist that worked for every type of Doctor.
No one design principles is beyond the sacrificial knife of design. That's just the way it is.