This post originated from an RSS feed registered with Agile Buzz
by Thomas Wheeler.
Original Post: Good Design and Software Construction
Feed Title: Random Artifacts
Feed URL: http://randomartifacts.blogspot.com/feeds/posts/default
Feed Description: Generally about agile, software development, and technical tips with occasional forays into other subjects.
As a software craftsman I appreciate the intrinsic beauty of good design. And I have an internal, almost instinctive, dislike of poor design. It's like seeing graffiti on the wall of a church, or listening to someone sing out of key. This alone is enough to make me want to write good code, and fix bad code. But good design doesn't just look good; and bad design doesn't just have an awful smell. It takes a lot less time and effort (costs less) to add features to a project that has a good design. And that benefits everyone -- developers, management, and users.
(By the way, when I say "design" I mean the entire application. Not just the Java or C# code, but also the build environment/tools, database scripts, shell scripts, architecture, etc.)
So how come so many projects have such a horrible design?
Nobody sets out to create a poor design. But many (perhaps most) projects end up being hard to understand and modify. Some eventually end up with so much technical debt that management decides it's better to start from scratch because it takes forever to get a new feature done. (Which is often another sort of mistake.)
So where does bad design come from? Here are some causes I'm familiar with:
Time constraints. In the midst of getting an application to build and work right, we often take shortcuts. These "shortcuts" are usually rationalized as necessary to meet an externally imposed deadline. Sadly, just about every excuse or justification we use to "save time" winds up costing us or our beloved colleagues ten times as much time tomorrow as we saved today. Another way of saying "we don't have time to clean up the code" is "it's going to take twice as long to add a new feature in six months as it does today".
Personnel changes. New team members can be great contributors to bad design, by writing code that breaks the existing design. Maybe because they don't understand it, maybe because they think they have a better idea (ego-driven programming). "Okay Steve, your first assignment is to add history tracking for all changes to the model. I'd work with you on it but don't really have time. You can stop by if you have a question, though."
New requirements. Sometimes a new requirement comes along which is incompatible with the existing design. The right way to handle this is to come up with a new design that is a good fit for both the existing features and the new one, and refactor the code. The common way to handle this is to "tack on" the new feature by hot-gluing it to the side of the existing code and slapping some paint on it.
Laziness. Yes, I am talking about you. And me. And John over there, and his buddy Adam who he met in college. Generally, if there is a "right" way to do something that is harder or takes longer, there's a pretty good chance we'll rationalize the easy, quick way.
Inexperience and ignorance. Whether it's a new technology we haven't used, a domain we're not familiar with, or a general lack of experience in development, not knowing the "right" way to get it done will almost certainly contribute to a bad design.
To put it another way, nobody intentionally prioritizes bad design. We just prioritize things that result in bad design as a consequence. Sometimes it's an intentional decision, possibly made with an understanding of the consequences and with the best of intentions to go back and do the rework necessary to clean things up later. Sometimes the decision is made unconsciously or in ignorance of the consequences.
The role of a software development team is to add value to the product. Bad design is a major obstacle to adding value. The most successful teams I've been part of have been rigorous and disciplined about using best practices to maintain a good design. And by the way, when I say "team" I mean everyone who is part of the project -- programmers, documentation, QA, UX, BA's, and management.
How disciplined is your team? What are you doing to help your team consistently adhere to the practices that result in a good design?
Previous Topic
