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.
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).
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.
