How Do You Think About Software Changes?

Home » Advice for New Developers » Software Architecture and Design » How Do You Think About Software Changes?
Photograph of columns in old building

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.

About Phil

I have been working as a software developer since 1983. This blog could have been called "From Fortran 77, C and Cobol to C# in 20 (not so) easy years", but it doesn't sound quite right somehow. Besides I'm talking about what's happened since 2003, not before!
One Response to “How Do You Think About Software Changes?”

Leave a Reply

Your email address will not be published.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">




Top Posts & Pages

Categories

Recent Posts

Recent Comments

Archives

Blogroll

  • Mike Cohn's Blog
  • Scott Hanselman's Blog
- mike@mountaingoatsoftware.com

In an ideal world, a Scrum team could perform the work of its sprints entirely uninterrupted. Produc [...]

- mike@mountaingoatsoftware.com

Do Scrum long enough and someone will suggest stopping the daily scrums. Here’s how to reply. [...]

- mike@mountaingoatsoftware.com

When estimating in story points, teams should think in terms of ranges and rounding up. Here’s why. [...]

- mike@mountaingoatsoftware.com

Batman would make the perfect Scrum Master. Once he eliminates crime in Gotham City, I plan on offer [...]

- mike@mountaingoatsoftware.com

It can sometimes be a challenge to get people to attend and then participate in sprint reviews. Here [...]

- Scott Hanselman

I love everything about PICO-8. It's a fantasy gaming console that wants you - and the kids in [...]

- Scott Hanselman

I've been a remote worker and an occasional YouTuber for well over a decade. I'm always lo [...]

- Scott Hanselman

I love me some text mode. ASCII, ANSI, VT100. Keep your 3D accelerated ray traced graphics and give [...]

- Scott Hanselman

Being able to seamlessly run Linux on Windows is making a bunch of common development tasks easier. [...]

- Scott Hanselman

I've been trying on and off to enjoy Ruby on Rails development on Windows for many years. I was [...]

Meta