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

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

- mike@mountaingoatsoftware.com

The standard “As a...I...so that…” user story template has stood the test of time. Here’s why each o [...]

- mike@mountaingoatsoftware.com

From helping teams understand the boundaries of self organization to creating safety around things l [...]

- mike@mountaingoatsoftware.com

Your team is probably spending too much time in sprint planning meetings. Here’s how to spend less t [...]

- mike@mountaingoatsoftware.com

Debating between Scrum and Kanban? Guest author Brendan Wovchko offers five advantages Kanban has ov [...]

- Scott Hanselman

There's been a lot of folks, myself included, who have tried to install VS Code on the Raspberr [...]

- Scott Hanselman

I don’t speak in hyperbole very often, and I want to make sure that you all understand what a big de [...]

- Scott Hanselman

I recently needed to refactor my podcast site which is written in ASP.NET Core 2.2 and running in Az [...]

- Scott Hanselman

.NET code (C#, VB, F#, etc) compiles (for the most part) into Intermediate Language (IL) and then ma [...]

- Scott Hanselman

Almost ten years ago I posted abut the SpaceTec SpaceOrb 360 Controller and that was 15 years after [...]

Meta