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

[...]

- mike@mountaingoatsoftware.com

As useful as user stories can be, they’ve never been right for every team. An exciting alternative f [...]

- mike@mountaingoatsoftware.com

Being a great product owner is hard. Here are the things your team wants from you to help them do th [...]

- mike@mountaingoatsoftware.com

Want to learn about Kanban? Here’s a complete guide to introducing Kanban into your organization. [...]

- Scott Hanselman

I had a lovely interaction on Twitter recently where a young person reached out to me over Twitter D [...]

- Scott Hanselman

With Visual Studio Code and WSL (Windows Subsystem for Linux) you can be in a real Linux environment [...]

- Scott Hanselman

It's a double-meeting that! Get it? "Outlook?" Seriously, though, sometimes folks com [...]

- Scott Hanselman

I blogged about NancyFX 6 years ago and since then lots of ASP.NET open source frameworks that build [...]

- Scott Hanselman

My colleague Tara and I were working on prepping a system for Azure IoT development and were using W [...]

Meta