I’ve come across a lot of developers who think about changes in terms of the existing software. While its important to assess the impact of any changes, its not the whole story.
How do you think about your software and how to change it if a new requirement comes up for example? Are you an inside out (or bottom up) developer, or an outside in (or top down), or a little bit of both?
If you have to make changes to meet a new requirement what do you think of first? The requirement or the existing software? A lot of developers I meet think in terms of the latter. Perhaps they think its risky changing software, so they want to change a bare minimum of what already exists. Perhaps they think existing because its there to look at as opposed to a new design that is still in the abstract.
I think its very worthwhile to think about the software design in terms of requirements if you can.
For example, if a web page (or portion of) is handling one thing at present, say GCSE results, and you need to cater for other types of results that have a different grading structure or possibly a free format grade rather than the usual A+ to F which at the moment is handled by a drop down. How would you meet this requirement? There is no right answer with design. It depends on your overall requirements and purpose of the system.
Many developers will just make a minimal change to existing pages to handle the new requirement, but the problem is, this makes them more complicated. More complicated means you are less likely to re-factor and improve the design in the future, because there is a greater risk of breaking something. As the design gets more complicated, it takes longer and longer for programmers to read the code and understand the impact of any changes. Eventually it gets so complicated its impossible to understand and maintain, and even the simplest of changes take a lot of time and involve a big risk of breaking something.
So often, a good strategy is to listen to the user requirements, consider making a new page (or component) for that requirement, and sharing other common components between the two pages (or components). Either way, you need at least one strategy to handle the complexity of non-trivial systems, otherwise they will get out of hand. If you put all your code in one place (in the code behind of an ASP.NET page) you are at risk of just modifying that code when requirements change because it sure costs a lot of thought to do anything else and in the end you lose because the software is impossible to maintain and needs junking and / or totally re-writing.
How to avoid this? You could start by starting to refactor it out into different libraries, by improving it bit by bit over time.
I am going to cover this subject a lot more in this blog. Thats what the upcoming series of posts on design are about. What a layered system looks like and how to start working towards this kind of design, without junking your existing software.