Software Architecture and Design: Where to Start

Home » Software Architecture and Design » Software Architecture and Design: Where to Start
Photograph of columns in old building

In time one of the main themes of this blog will be about software architecture and design.

There are many different terms used to describe this important subject and sometimes they are used interchangeably. In this blog, “Software Design” will mean the internal design of programs, “Software Architecture” will mean the organisation of, and relationship between, different programs used to make up a system.

So “Software Architecture” refers to the overall system design and “Software Design” refers to the design of objects and components within a program used in the system.

I think this is a very important topic that is not covered that well elsewhere. A lot of example code you see on the web, or books you read about programming, even examples from professional companies that sell third party libraries for example, include anything about architecture or design.

So why is it important?

Well in order to write software you do some kind of design whether you think about it or not, I think its important not to take the default option and not think about it before you start writing code. The time spent writing the system, the efficiency of it and the ease of maintenance are just a few things affected by good architecture and design.

Wikipedia has a good definition of software design, but the things we are interested in are basic architecture and the SOLID principles for design which help you to organise your code in a much better way than the default “Thick Client” way. The idea being that you use object orientated design to organise your code into more but simpler classes that are easier to work with than just having one big page class and throwing everything in there. Managing the dependencies between these different classes, components, objects (call them what you will) is one of the key software design skills.

Diagram showing typical multi layered architecture
There is no right or wrong way to do software architecture and design, but having thought about it, you will at least have a plan and you will avoid the default option of the “Thick Client” approach that I have seen and laboured with so many times in the past for various customers. “Thick Client” is where you just use the “Code Behind” option in Visual Studio and build up an application on a page by page or form by form basis. All the logic, everything goes into the pages, so in the end the system is one unmaintainable morass because all the features of the software are spread across many different places. I worked on a ten year old system that had been developed like this a few years ago, and despite working on this system for months, there were so many interdependencies in this system, it took hours and hours of reading code to understand what was happening before one dared to make a change. This system was slow, unreliable and making changes to this system cost 100’s of times more than what they should have cost, had the system been designed better in the first place and up until my joining the project nothing at all had been done to improve matters. The “Thick Client” approach is only really suitable for prototyping and only then if the prototype is going to be thrown away (not something I do very often – Agile thinking takes a prototype and develops it into a real system, so thick client is most definitely out at any point).

Diagram showing typical layered software architecture
Please note, I am not calling anybody “Thick” here, certainly not my customer. Thick Client refers to the fact that all the code, everything, is in the Client (User Interface) layer. One of the goals of software design is to separate out the business logic (and other components such as data access) from the code that must be there to glue everything together and to make it work – the “Plumbing” for want of a better term. This is a topic that will be explored thoroughly in future posts.

So what’s the alternative to “Thick Client”? How can I fix a system that I come across that is bad in these respects? How should systems be designed? Where can I learn more about it? How do I tell the difference between good and bad if I don’t have experience of the good? Where does Agile fit into all of this? How about TDD (Test Driven Development)?

I will try during the course of this blog to come up with some good posts that answer these questions and more, and also illustrate different aspects of this important subject, with worked examples.

More on SOLID principles

If you haven’t heard of the SOLID principles before, there are many resources on the web. Two I have picked on are the MSDN overview of SOLID principles, and Uncle Bob being interviewed by Scott Hanselman about SOLID principles – this also has a transcript in PDF format if you prefer to read rather than listen (I listen a lot in the car when driving out to see customers). I need to go into a separate post to even start to do SOLID justice (and then there is the question of examples). It does take a while until something suddenly just clicks and then you find you think that way automatically. One final link for now on SOLID is the SOLID post on Stack Exchange.

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!

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