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

One of the benefits of being on a team is the friendships you can make with your teammates. Many of [...]

- mike@mountaingoatsoftware.com

I wrote 24 blog posts during 2019. In case you missed some of them, here are the most popular. [...]

- mike@mountaingoatsoftware.com

It’s coming on Christmas. That time of year when I drop hints to my family about gifts I’d like. [...]

- mike@mountaingoatsoftware.com

[...]

- Scott Hanselman

At the start of a new decade and over 700 episodes of my tech podcast, I did something weird. I had [...]

- Scott Hanselman

I often talk about how .NET Core is open source and runs "everywhere." MonoGame, Unity, Ap [...]

- Scott Hanselman

Hey! Did you know I have a podcast? A few actually but Hanselminutes has been doing for over 700 epi [...]

- Scott Hanselman

Now that .NET Core 3.1 is LTS (Long Term Support) and will be supported for 3 years, it's the r [...]

- Scott Hanselman

I did a post on the difference between a console, a terminal, and a shell a while back. We talk a lo [...]

Meta