Design and Architecture: Is Good Design Worth The Effort?
As a software developer, I have unintentionally surrounded myself with other software developers who share the same ideals as myself. If you asked any them if good design is worth the effort, they will answer with an unequivocal yes! They may ask “How can you question design? It is the heart of software development.”
Project managers will stand behind us, nodding in agreement, because no project manager is brave enough to openly say that design isn’t a worthwhile activity, instead they’ll rephrase their disagreement: “We have a deadline approaching and we need to get this functionality out of the door fast!” A dangerous phrase which means they want you to churn out code as fast as you can without regard to future costs.
Software developers use the term “Technical Debt” to describe the obligation an organization incurs when it chooses a design or approach that’s quicker in the short term but increases complexity of the software and is more costly in the long term.
Imagine, skipping the dishes after dinner, instead of washing them you let them pile up in your sink, you’ll save time now, but eventually, you’ll have a huge mess in your kitchen and you won’t have any dishes to eat on. Even worse, imagine that your in-laws drop in on a surprise visit and you don’t have any dishes to serve them food on—these imaginary in-laws are clients asking you for new functionality.
Technical debt prevents you from meeting your customer’s needs quickly, modifications to the code base take exponentially longer and as your technical debt accumulates you expose yourself to more risk.
Sometimes, just like financial debt, it is beneficial to take on technical debt to exploit an opportunity, but like credit card debt, the interest on technical debt can catch up on you, all too often we don’t manage our debt, it spirals out of control and we spend most of the our money paying of the interest, not the principle.
Software development is a series of compromises, but we can’t fool ourselves into believing that we can trade good design for greater development speed.
The problem with sacrificing design is that the code becomes unstable, adding a feature will break the software in other places; the code becomes to modify, a simple change requires modifying other parts of the system and finally, the code becomes harder to read, developers spend days trying to figure out which files need to change. Eventually, your developers will become frustrated and they’ll start proposing the big rewrite of the system.
Development in the absence of design yields systems which have a high level of coupling, where functionality is spread across the entire application and often duplicated in several locations across the code base.
As the application evolves, these duplicate functions become unsynchronized, making bug fixes more difficult and time consuming. Maintaining a code base with high coupling is difficult and time consuming, your developers waste time looking for the code to modify searching for the duplicate code in ten different files, instead of developing new functionality; they waste time re-understanding the code. All of these problems compound to make maintenance and further development extremely expensive.
Programmers are lazy and if good design actually increased the effort and time required we’d be against it. Software design is an effortful activity, but one which leads to a net increase in productivity and efficiency.
For software to remain relevant and profitable, it must change often, add value by growing in features, if your code is brittle and fragile, then adding new features to your application is difficult, eventually you’ll have to turn away customers because you can’t meet their requirements in time. Extrapolate this over five years and imagine the profit you had to forgo because your code is unstable.
Good design ensures functionality is confined to a single location, it encourages code reuse, makes maintenance easier and it makes it easier to add new features, in short good design saves you money.
June 5th, 2008 at 9:35 am
Agreed on most of the points. Though, there are some tiny projects in which some time we have to forget about design. Though, it would be a very good idea to write every code like poetry. Everything should be designed / write according to the principles.
I have been working on a pretty large project for a client. That project has been written in PHP and we have strongly used Zend Framework. When our client requests or complains about any issue, due to the good design of the application, it is very easy for me to fix / add anything to that. So a good design helps me in maintaining and scaling the application fast.
Now the next post should be on adding comments / documentation to your code.
June 5th, 2008 at 4:06 pm
Totally agreed. A good design in an earlier phase can save you tons of time and effort later. Unfortunately design efforts are often ignored due to deadlines and other constraints. I know of a poorly designed project that has been in execution for more than couple of years. The project has now wrapped up with so many fixes (each creating possibilities of new bugs) that it is now consuming full working hours of 2-3 personnel. I am pretty sure that if we re-design its architecture, it would relieve everyone but the client isn’t willing to do this now. Such scenarios aren’t rare in software industry.
June 5th, 2008 at 9:41 pm
Mehroz,
You bring up a good point, design is ignored to due deadlines, companies are more than willing to waste developer productivity (read: money) in the long run for a quick profit. I believe this is because they don’t realize how much money they’re losing, they rather bleed away nickels and dimes for their entire life than a $100 at once.