Sixteen years ago I was working on a VB6 Access VBA contract. The first version of .NET had yet to be released. About that time Microsoft brought out a version of Java which was not widely accepted due to it being different to standard Java (and developers not wanting Microsoft to control Java), which led I think to the birth of C#. How times have changed since then. Despite coming up with many innovations of its own, Microsoft has been playing catch up big style in the past sixteen years in terms of software architecture. Many ideas have come over from the Java world into .NET and C#, many of them really good and which have moved the design of .NET software for the better I think.
In this series of posts I would like to introduce some of these as if you have never heard of them before, and then in future posts I’ll delve into more detail. I hope this is the first post of eventually what might be an interesting series on software architecture and at least I will have a good resource to show people when they ask about it.
I would like to add that despite putting as much time as I can spare into personal development, this is such a big area and there are so many new things coming out, that its impossible to be an expert in everything even if you devoted your entire working life to it. I have found for many years, like my wife, who is a scientist in a totally different area, that the more you learn the more you release how little you know. I think that’s definitely the case here. That is no reason not to learn about it though, because even just one little thing can change the software you write for the better.
Everybody seems to be talking about Agile as though its a new thing, but its going on 20 years old. The Agile Manifesto was written in 2001. There are various flavours of Agile techniques, but all I would like to say in this post is that one of the founders of the Agile Manifesto has written a book that is a really easy read that gives a really good overview for managers and developers alike.
Please see the page on Books about Software Architecture and Design on this site for further information.
Object Orientated Design (OOD)
Pure OOD can be quite abstract to the needs of a form or report you are writing. However there are big benefits in terms of the code that needn’t make things more complex. In fact good architectural design can mean the code in more readable and the intent more visible, with much less code, so its easier to spot bugs before the code gets released. OOD is a big part of this. One of the benefits is have more but far simpler and shorter classes and methods. Another is that many design patterns will separate out functional code from plumbing type code that while essential for the code to work in the real world, is code that is muddies the picture with extra complexities and dependencies when trying to read what the code does.
If you are at the level where you know what a class is, properties, and just a little of the theory about inheritence etc because you have used Windows Forms or Web Forms, then there is a lot of good things to learn. I can’t recommend the following book any higher:
Domain Driven Design (DDD)
Eric Evans brought out what is now a classic book, Domain Driven Design, he might have even coined the term (can’t remember). The whole point of DDD apart from to have a common language to discuss a system with, is to have the business domain at the centre of any system and it should be produced without any dependencies on other layers such as UI and database, in fact other layers should depend on it (i.e. the references should point inwards). This can result in the business logic for a system all in one place, in pure C# or VB.NET classes and methods, which has to be far better than having it splattered all around a system and all its objects to the point where its difficult to find all the business logic, let alone see what it does.
This book is a very interesting read for managers and developers alike:
Extreme Programming (XP)
At first glance, Extreme Programming (XP) has dozens of rules that are impossible to memorise or understand without a lot of study. The reason why I’m mentioning it here is that it may be possible to pull some of the techniques out of it to use, with no need to implement fully (or have a gradual implementation). Agile and XP are the two places to look when in need of inspiration, Agile has been going 20 years and XP 15 (2001 I think it was) and have been continuously developed and improved during the time. Who am I to think I have a better way? At least I should look and see if any part of it helps me, or can be improved upon without re-inventing the wheel from scratch.
Also, when looking to leave the campsite tidier than you found it (i.e. code in a better condition than when you found it), how do you know what “better” is without having some guidelines? Thats one of the objectives of these posts – to try to give pointers to where you can find this information, without linking to specific articles that may be out of date in no time.
I think the following book might be out of print but its still available on Amazon as I write:
My favourite XP “thing” – the concept of a spike – where you take a very small part of a system functionality and implement it fully – so all the different angles, database access, ui, localization, everything can exist just for one form. You might end up with loads of stubs and comments but that’s the whole point – to work out the overall architecture of the code and where everything goes ahead of time so you can work in the right direction from then, rather than having to come back and re-factor.
Next Post in this Series
In the next post I will go into some more detail about important architectural concepts and include more links for information for the reader.