A Blog about Coding

Category: Software Architecture and Design

  • The Right Approach to Developing Software

    The Right Approach to Developing Software

    I have not blogged for some time due to pressure of work, instead I tend to record ideas for blog posts on my kanban backlog… and they just add up.

    Anyway, this post covers a couple of points highlighting different approaches to developing software which I have noted while working in the industry.

    Code First or Database First?

    I’m not talking about the Entity Framework methods of creating data models / databases here.

    Is there more code in your system than there needs to be and / or is it more complex than it needs to be? This is subjective of course, but if so it is a major indicator that your database model / designs could be improved. A consequence of improving these designs is that the code becomes trivial. The purpose of any system is to translate the data model into concepts that make sense to the user. If the data model is designed with user requirements in mind, then the task becomes far simpler.

    I remember 20 years ago a system I worked on which was for contract management for a big UK company.. This involved a major modification to an existing system. But management had decreed that there would be no contract table in the database….

    System Requirements First or User Requirements First?

    When making a change, say user A asks us to add a feature to system B, then there are two ways of approaching it.

    1. We could look at system B and work out which pages, methods etc. need to be changed, to allow for the easiest possible change with minimum changes.
    2. We could look at the design, the concepts of system B if you like from the users perspective and give them something that fits the requirement really well while putting the actual changes needed to the system second.

    Many developers, especially the less experienced, when under time pressure are much more likely to think about the former approach and not care / understand too much about where the user is really coming from and what their needs are. The best systems often fill a strategic need for the user in a really elegant way, and these are often the result of the second approach.

    Often the result of using the first approach (i.e. minimum changes) is to end up with a slow, complicated unmaintainable mess that doesn’t work properly. In other words the first approach is not always the best approach. Just because you can change something a given way doesn’t mean that you should. The first approach doesn’t always result in a shorter development time either, esp. not when you include the time for support.

    So just because you can change a system in a given way, doesn’t mean that you should.

    Other Indicators

    1. If you are copying and pasting code, stop and think why?
    2. If you are adding data access code in a code behind or a MVC controller, stop right there. Whats stopping you creating a class library and moving the data access code at least into it?
      Or much better, make a service class library and reduce your controller / code behind code to just a couple of lines. Your code will immediatley start to improve. I don’t care how you then structure your class library, the fact that you have split UI and business / data layers is a major, major win.
    3. If you have methods that are pages and pages long, either you are coding them wrong, or your database design is wrong, or both.
    4. Have you got response times longer than 2s on your internal network (WAN access to webservices might be beyond your control)? If so then it may be you are adding everything into a smaller number of views and tables than you should (yes some companies still use Views and Stored Procedures… its ok in my book depending on the circumstance).

    Conclusion

    There are a couple of things I’m thinking about at the moment:-

    1. How best to layer software, e.g. user interface (MVC, MVVM), service layer, business logic, data layer, helpers, that kind of thing.
    2. How best to link different systems together. The old way of using contractors to weld systems together the so called “Best of Breed” approach, falls over when a new version of a system is required. I have refused these kind of contracts for the past ten years or more. The modern way to approaching these kind of integration tasks is to define the interfaces between different systems and using message queing (NServiceBus or RabbitMQ) to handle the interfaces. This has the additional benefit of allowing each system’s individual database design to be under control of the system developers and be changed to meet the needs of that system.

    I hope to blog more about this in the future, time allowing.

    Happy Coding!

  • 14 reasons why Tight Control of Software Projects doesn’t Work

    14 reasons why Tight Control of Software Projects doesn’t Work

    With the advent of Agile techniques, thankfully companies that try to control every aspect of a software project in order to measure progress are becoming a thing of the past, thankfully far fewer than twenty or thirty years ago when I started as a software developer.

    I blogged about the dangers of tight control a while ago, in January of this year, in The Dangers of Planning Time on Software Projects.

    I also recommended Ron Jeffries book, The Nature of Software Development recently to people who had not discovered Agile techniques. Ron is a founding member of the Agile manifesto and this is an excellent introduction to managers and developers alike. In his book, Ron states that it is a bad idea to try to create tasks and control these within a sprint and even if you must do that, don’t specify stretch goals which are tasks that developers “get to” if they finish other planned tasks.

    I was looking for a really good introduction to Agile to be able to recommend to others and this book definitely is it. Anyway on with the post. Why does tight control not work for software projects?

    Estimation

    1. Software Development is Design, not Production and it is impossible to estimate tasks accurately, certainly anything like half a day, let alone less than that. You cannot see the details at estimation time, and if you can you might as well have done the work having far increased your time by giving such a detailed estimate.
    2. If the developer is doing something that has not been done before, either for themselves or for the project, it will likely take longer and be more difficult to estimate. If it involves learning something new – a pattern or technique – the estimate could be 3 or 4 times over. This is hard to justify without looking bad in front of your manager (if your manager doesn’t understand).

    Extra Overhead Involved

    3. Developers are not always the best documenters so many details are very difficult to justify.
    4. Documentation is required to communicate with managers both on tasks and on making copies of technical details because managers cannot read code (using techniques such as Domain Driven Design or just plain good object orientated design, modern code can be structured in such a way that the intent is visible in the code, so no need to duplicate lots of small details in Word and Excel spreadsheets, that then need to be maintained). Note: this is not an excuse for Agile projects to document or design nothing at all but what is documented must be properly maintained along with the codebase.
    5. It is not always possible to explain and justify detailed concepts to a manager who was a COBOL programmer once but doesn’t really understand that he/she doesn’t understand modern practices and patterns. Result: either a lot of time spent trying to justify, or the detail might just get missed, or a simpler to justify technique (that is worse for the project) might be used instead. Maybe you just start coding and hope for the best…
    6. There is a risk that tasks will be specified from above in an inefficient or impossible to achieve order, which dictates creating software components earlier in the development process than otherwise would be the case. Agile techniques leave detailed decisions until they need to be made. They are not over specified up front. Also concentrating on Agile’s value proposition and continuous delivery helps mitigate this problem in any case. I once worked on a big project like this with nothing whatsoever to deliver until the end – the “big bang” approach which is one of the reasons software projects fail – the requirements move on so much during the time the software is being developed, its unusable when delivered.

    Overruns

    7. If an overrun occurs, the developer is then full time on the extra overhead of trying to justify why the estimate was wrong and updating the task database when the developer should be concentrating 100% on delivering the correct solution for the software rather than breaking a chain of thought that led to that point.
    8. If a concept or technique is developed that isn’t 100% correct first time round, then extra time will be required. Does the developer soldier on and keep their head down, or go to their manager and ask for more time and incur a lot of justification, admin and look bad in front of their manager? Or do they ignore and just complete the task the best they can thinking they can come back later? Agile techniques practice continual improvement in response to continual change and learning of requirements from customers. The developer is continually re-factoring and improving code. The non agile manager could see this re-factoring as paying for the job twice or worse when the opposite is the case.

    Technical Debt

    9. The risk of technical debt if there is too much interference (from any of these points), or if there is nobody in the team to shield the developer from excess pressure. All teams need senior developers in my view, to help shield excess pressure from above, to help with strategy and to guide and develop other developers skills in a way that is beneficial and doesn’t impact projects too much.

    Trying to Monitor Performance

    10. Monitoring performance is a management problem, that management should ideally carry out with a minimum of interference on the work involved. Many in the NHS or schools have this problem. Because the politicians need “facts” so they can cherry pick and obfuscate them for their own ends, they double the overhead in these places just because they need figures they are going to change anyway. Who wants to work for a job with the prime minister looking over your shoulder telling you how to do your job? Thankfully in software, we have Agile techniques that allow us to avoid this problem.

    Other

    11. The risk of constraining the project to a size and complexity that a manager can understand all the details or to what can be justified to managers. Even though Larry Page and Sergey Bryn are good programmers, at Google engineers stopped both from programming early on in Google’s history, possibly for this reason, I don’t know for sure I wasn’t there.
    12. Sometimes there are times when the team knows what do do. Management (team leaders included) should just get out of the way and the developers should get on the best they know how without hindrance.
    13. Finally education can suffer. Development by its very nature is a learning process where the team learn about both the application they are producing and the best techniques to use as they go along. Not allowing time or budget for education, especially if this impacts your software architecture is a really bad thing. Also these kind of companies can’t justify 20% time such as that practised at Google, where 20% of the time developers are free to develop anything they want – this will be normally things that better their own skills and the companies fortunes but which they can’t justify in advance to a manager. The classic example of this was Adsense at Google but I am sure there are many among the enlightened companies that allow 20% time or who have good developer training budgets.
    14. Often projects like this will overlook architecture considerations, correct object orientated design, or domain driven design, because the managers controlling don’t really know what they are, how they relate to a project, or why they are so important and useful to ensuring the absolutely best product is delivered in the shortest possible time. Result: Work has to be done many times over and due to the lack of architecture contains many bugs rather than being bug free first time, and is never right, or anywhere near as useful to the end user as it should be.

    All or any of the above can double or triple the size (time taken) of a software development project. Tight control is really unnecessary in this day and age. Not having a route to channel concerns or make those concerns hard to justify, can double or treble it again, as can not having a suitable developer or manager to shoulder and handle excess pressure from management. Excess pressure leads to code smells and technical debt. This is without considering the actual practices and patterns used when developing the software.

    I have worked on some projects where even getting a web project to use caching has been a mammoth task and has taken a couple of days writing detailed documents and then a couple of months to schedule a meeting to discuss the document just to try and justify it. A couple of days is enough to develop and refine the caching algorithm to use and trial it in the project to see what actually works for the system and letting the results speak for themselves. That is the point of Agile – don’t try to justify anything, let the software speak for itself and if it isn’t right, change and add to it until it is.

    How to avoid these pitfalls? Follow Agile techniques. Measure what is actually planned and delivered for each sprint, and leave the developers to get on with each sprint without hindrance or slowing them down by asking them to do admin tasks and justify being there all the time. Control the project by changing priorities based on value delivered for future sprints. Do not mess with current sprints where at all possible. Do not over specify to the nth degree and then interfere with the detail as well as the time being spent. Specify all requirements in user speak. Do not try to tell the development team how to do things and when to do them apart from specifying requirements and sprints to do them in.It really is a recipe for disaster.

    Ron Jeffries book is on my Software Architecture and Design Books page. Highly recommended.

    Another way of looking at all of this is to be Agile and measure on results – i.e. on deliverables delivered within timescale and budget, not on specific detailed data. If your project is not delivering, ask yourself why. You can also contact me and ask me why if you like. If you are open to new ideas, I’ll come along and help you sort it all out – to your complete satisfaction – no problem at all.

  • Technical Debt isn’t a Technical Problem

    Technical Debt isn’t a Technical Problem

    I listened to an old podcast from Dot Net Rocks recently Technical Debt isn’t Technical with Einer Host, which went on to explain how Technical Debt isn’t a technical problem.

    Using Agile techniques, once the sprint has been set by the product owner, programmers are left to themselves to organise the work and to slowly build the software feature by feature, while keeping a fully tested releasable version of the software available at the end of every sprint.

    Wikipedia (https://en.wikipedia.org/wiki/Technical_debt) says:

    Technical debt (also known as design debt or code debt) is a metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper”

    Some technical debt is inevitable due to the nature of the very iterative, simplest method possible way of programming in Agile, but it is constantly re-factored out and improved upon as the work progresses. If it is not, it means the work done so far is probably adequate and the debt is a very small thing that works but possibly is not best practice, but is such a small thing it doesn’t really matter or affect anything.

    There is another side to technical debt however, that is if the team is not really Agile, and there are problems with management interfering or trying to control work, or by trying to set deadlines rather than measuring velocity, then an amount of technical debt that can build up that eventually slows the project down to the point where further development work is very difficult, expensive and time consuming. This problem is as bad as not using good design in the first place due to having a very inexperienced team doing the work.

    The Wikipedia article lists many more reasons for technical debt and the pod-cast was a very interesting listen. The common causes listed in the Wikipedia article all fall into two categories:

    1. Management Pressure to try to push or control things resulting in things being done in the wrong order or not at all
    2. Inexperience on the part of Developers

    The answer? In my view, try to follow Agile practices as far as possible, because the more a project does something that is new, the more a project can benefit from Agile techniques. Agile techniques can handle uncertainty and change better than any other method we know. I also believe that seniors should work to support the whole team in terms of knowledge and ensuring they have enough time to carry out their work and also shield the team from management pressure (although not allowing the current sprint to be altered after it has started except by developers themselves goes a long way to doing that).

  • Getting Started with Software Architecture in C# or VB.NET (Part 2)

    Getting Started with Software Architecture in C# or VB.NET (Part 2)

    This post is part 2 of an introduction to Software Architecture in C# or VB.NET. Part 1 covered some concepts, this post goes into a little more detail about programming by interface and SOLID principles by Uncle Bob Martin.

    Programming by Interface

    An interface is another layer of abstraction. Why bother? I’ve heard this from many people, especially people who are more inclined to look at the existing system to work out what to change, rather than look to a design of how things should be. I blogged about this a while ago.

    Programming by Interface is an important concept whether you are interested in TDD or not, because it allows you to control (by explicitly defining) how different modules link together, i.e. dependencies. It also allows you to plug in TDD on anything you see fit, e.g. complex business logic that is absolutely fundamental to the working of your system.

    Interfaces can be inherited just like classes can. It’s the interfaces that define functionality and dependencies, the concrete classes just come in to fulfil the needs of an interface at runtime.

    This is where Dependancy Injection (DI) is typically used, just to plug in concrete classes when needed – for a certain part of the design. So you use new statements (or factories) in your design for certain classes, and DI instead of new statements of another set of classes. E.g. Model’s, Forms and Reports are not injected. Objects that work on the model typically are.

    Interface vs Abstract Classes

    These are more or less the same thing but slightly different. Abstract classes can provide some functionality (an interface can provide none), and also have a parent, so only single inheritance is allowed. Abstract classes should only really be used for “IS A” not “HAS A” relationships.

    Programming by Interface is the most important concept I will blog about in this overview. You should try to learn as much as possible about this because interfaces explicitly control the relationships, i.e. dependencies, between objects. They are very important, not just for those interested in TDD. To find out more, apart from search for terms like “Programming by Interface” search for terms like “Composition over Inheritence”. Wikipedia has an example of Composition over Inheritence.

    SOLID Principles

    Uncle Bob Martin came up with the SOLDI principles which then were modified to SOLID during an interview with Scott Hanselman on Hanselminutes a while ago.

    I am not going to try to define them again – a link to Uncle Bob at the end of the post does that – but I would like to comment on each of the five main principles:

    S – Single Responsibility Principle

    Classes and methods should do just “One” thing.
    The “One” is a matter of judgement viewing all your code in context. It doesn’t mean that each method can only be one line of code!!
    You end up with many small classes and methods, which actually are easy to name because although you have a lots of them, because they only do one thing, they are easy to name. Class, methods, variable names should be descriptive (no need for comments).
    Also cross cutting concerns can be implemented via helper methods (one place where statics are used) and they can be put in to certain classes (or injected in via DI or PostSharp).

    O – Open / Closed Principle

    Classes should be open for extension, closed for modification. So inheritance is always needed. One of the key OOD principles is to encapsulate what changes. So when decided what to put in a class and what can be virtual, this is a good guideline.

    L – Liskov Substitution Principle

    When using a class, you should be able to substitute any other sibling into that code without breaking it. The rectangle/square problem is a good one – I’m not going to go through it all here – but its down to should a rectangle inherit from a square (or vice versa). The answer – not it should not. Because they are different shapes and it would also violate this principle.

    I – Interface Segregation Principle

    Clients should not be forced to depend upon interfaces that they do not use (Clients being any consumer of an object, i.e. another object). This is about the structure of the interfaces between classes, keeping them small. This does not mean that you alter the layers in a layered system (see Microsoft Application Architecture Guidelines). For example, a DAL could / should? Have lots of small interfaces but containing say all the columns in a given table, the Business Layer could take advantage of whatever it needs without having to change the DAL to add extra columns etc. that are already in the table, but the façade layer that delivers the data to the UI (via WCF or otherwise) could have bigger, amalgamated classes that contain all the data needed in that transaction so only one call is required, specifically for that interaction.

    D – Dependency Inversion Principle

    High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. This is ultimately about having the references in your visual studio project pointing the “Right” way, e.g. if you have circular references you are probably missing a layer of abstraction.

    http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html is one of the best intro’s I’ve found on the web.

    The book Agile Principles, Patterns and Practices explains SOLID far better than I can – see below.

    Whats Next

    Now that I’ve summarised what I think are important concepts, in future posts I’ll go into more detail as I come across examples etc.

    Further Information – Links

    SOLID

    http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod – definitive guide from Uncle Bob’s Blog

    http://www.davesquared.net/2009/01/introduction-to-solid-principles-of-oo.html – A good introduction

    Microsoft Application Architecture Guidelines

    A very good read

    https://msdn.microsoft.com/en-us/library/ff650706.aspx

    More about Dependency Injection (DI)

    (I don’t recommend Unity because its slow but it’s a good tutorial):

    https://msdn.microsoft.com/en-us/library/dn223671(v=pandp.30).aspx

    More Links

    www.hanselminutes.com

    www.dotnetrocks.com

    http://www.dnrtv.com/

    A couple of interesting shows from Dot Net Rocks:

    https://www.dotnetrocks.com/?show=1235 – very interesting bit about technical debt

    https://www.dotnetrocks.com/?show=727 – Steve McConnell – author of Code Complete and www.construx.com

    Uncle Bobs videos are very good and are available at a price on https://cleancoders.com/.

    There may be a few examples on his site that are free – and he is not on Pluralsight unfortunately.

    However searching for SOLID on YouTube is another possibility.

    Further Reading – Books

    If you are going to read just one book, then Head FIrst Object Orientated Design is the one followed by Agile Principles, Patterns and Practices in C#

    The books are listed in approximately the order you should read them if you haven’t read anything on the subject.

    Beginners

    Intermediate

    Advanced

    This post has not mentioned anything about the core C# programming skills that every C# programmer should have – see my page on C# programming books for further information.

  • Getting Started with Software Architecture in C# or VB.NET (Part 1)

    Getting Started with Software Architecture in C# or VB.NET (Part 1)

    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.

    Agile

    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.

    Summary of Resources

    Agile Manifesto
    This Site: Books about Software Architecture and Design

  • Software Design and Architecture in .NET

    Software Design and Architecture in .NET

    The reason for me producing this blog in the first place is that I wanted to share and develop my knowledge of object orientated design, including layered and tiered software and software architecture in general.

    To do proper justice to these subjects could take more time than I have had available in the past few months, with a house move and lots of work commitments. Hence it has not yet been attempted.

    I am intending to put the effort in though especially with having some time available over the christmas break. This post is the first of hopefully many on these two subject areas.

    Just to define Design and Architecture for the purpose of this blog.

    In this blog, design is the effort you put into designing an individual application or database to meet your user requirements.

    Architecture is relating to the relationship between different components, in particular the relationship between different applications in a system that is made up of well, different applications.

    So for example, talking about layered architecture is really design if these are layers (i.e. classes in the same app) or architecture if there are multiple tiers (e.g. part of the app in a WCF service, the other part in MVC or WPF).

    In coming posts I am going to explore both angles.

    Software Design

    I see too many systems that just kind of expand outwards, into what are called “Thick Client” type of applications. That is, all code goes into a single code behind class (or possibly stored procedures and views in the database – resulting in a Thick Database, which is just as bad). Also systems I have worked on are both “Thick Client” and “Thick Database” with nothing much in-between!

    These systems are common in my experience and are very easily done when your DBA says he/she always wants stored procedures, it might be difficult to make changes to the database, and the software itself expands out in the code behind as new features are added without time (or tests) to allow easy refactoring of the client side code.

    While there are plenty of ways to design a system correctly, there are also plenty of ways to get it wrong also (what’s the definition of right or wrong – well you decide that – if you are happy with your system, if its reliable, meets your users needs, easy to maintain and enhance, then there is nothing “wrong” with it – most systems can usually improved in one way or another though, because nothing is perfect). We are going to journey from examples of such a system in various directions that undoubtedly improve matters, giving the reader the information and tools to be able to make better decisions about where to put the code.

    Software Architecture

    Software Architecture is a different subject. How should components and systems talk to each other? In the case of components where to put the breaks in tiers, what classes go in what tier. How to change if you get it wrong, etc. In the case of systems often it is a case of finding out what the published interface is if any and using that, or if not, making a WCF service that uses SSL transport that can access the database and at least make a start at making it secure over the internet. But how to design these services? How to make them resilient? Talking of resilient, how to handle one system, one database, or one component being down and unavailable? Showing users the error page isn’t always acceptable.

    Also the methods used to integrate different systems together have changed over the years. Years ago it was “Best of Breed” and “Enterprise Integration” that were the buzzwords. Then SOA (Service Orientated Architecture). You cannot say you are using SOA just because you are using WCF! There is a lot more to it than that. What I am looking for is a low cost way that just allows developers to concentrate on business logic rather than plumbing code, so we will look at brokers like Microsoft Biztalk and its more developer friendly alternative Windows Workflow Foundation (WF) and also products like NServiceBus (to be fair Biztalk can act like a Bus as well as a broker).

    During my career I have been lucky enough to be able to work on lots of different systems I can add some really valuable posts. Watch this space!

  • Should Software ever be Re-Written?

    Should Software ever be Re-Written?

    Should software ever be re-written?

    Technology is always changing, new versions of development tools, databases, third party components continually appear. In fact about ten years ago somebody said it was a full time job just to keep up with the new tools coming out of Microsoft. If anything in recent years, especially with the advent of Windows Azure, this situation has got worse. So surely, software is obsolete the minute it is written, obviously we should re-write software that we develop every two or three years, right?

    Some companies that I have worked for over the years have exactly this strategy. I feel though, in my experience at least, that this was politically driven. There are many good reasons not to redevelop software.

    • If it isn’t broke, why spend a fortune redeveloping it just to say develop in Angular or Kendo UI when plain old webforms will do? Again this re-development will be obsolete as soon as (or before) it is finished
    • The business can spend its money on other business benefits, such as add on modules that provide further benefits
    • There are also better things for developers to do as well than re-write old systems

    Against this, you may have to re-write if say the platform (operating system, database etc) becomes obsolete. Or if the software no longer meets business needs. If the software becomes impossible to maintain due to its age and number of changes that have been made to it.

    My advice to customers is that if you make careful decisions regarding platform, and go for industry standards such as Microsoft .NET, SQL/Server, Oracle etc., then in this day and age, especially with all the open source code, jQuery, etc., there is no reason not to have software that lasts for decades. The key as a developer, is to keep it easy to maintain, so its easy to change. One way to do this is always to leave code in a better condition than you started with it. The business on the other hand has to give you enough time to be able to do this.

    The way I look at software is that above all else, the software is a detailed design specification. It must show the programmers intent, i.e. the detailed requirements of the business, when reading the code. Code must be well organised and super readable. This is harder the more people in the team, particularly if they are geographically separated and work for different companies. But it is possible. There are a number of things that can help.

    • Domain Driven Design
    • SOLID Principles
    • Agile Methodologies
    • TDD
    • Patterns and Practices
    • Object Orientated Design
    • Good Database Design

    Obviously not all are needed in the same project. Only you can decide what is appropriate for your requirements.

    In the coming months though, this blog will try to examine the above and more with lots of examples. Please be sure to send me feedback and let me know what you think.

  • Object Orientated Design and SOLID Principles – Dot Net Curry

    Object Orientated Design and SOLID Principles – Dot Net Curry

    I read DOT NET Curry on a regular basis. One of the things that I think is really important to understand is object orientated design and the SOLID principles originally documented by Uncle Bob Martin.

    I’m not going to repeat what has been said by others, this blog will focus on some (hopefully) well thought out examples, but this post links to some of the resources I have found interesting. There is a wealth of information on DOT NET Curry.

    1. SOLID principles by Uncle Bob Martin
    2. DOT NET Curry – Object Orientated Programming
    3. DOT NET Curry – Single Responsiblity Principle
    4. DOT NET Curry – Software Gardening Articles
    5. www.oodesign.com – useful site for those interesting in learning about design patterns

    Why should you care about SOLID principles? Isn’t it just something else to remember? The main thing in my mind is that it changes your way of thinking away from the existing code into more about what the code should be doing. Also having more objects, but better named, shorter and simpler with less dependencies really is a breath of fresh air – it makes a system really reliable and easy to maintain if you can read the code. In my view, all developers should study SOLID principles to understand just how readable your code could be, before you decide if you should use this or not. Code readability, whatever methods you use, is very important. If your code is readable enough, you can spot many of your remaining bugs just by reading it.

    For those new to object orientated design, I highly recommend Head First Object Orientated Analysis and Design on my Software Architecture and Design Books page.

  • How Do You Think About Software Changes?

    How Do You Think About Software Changes?

    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.

  • Should you use Third Party Software Components?

    Should you use Third Party Software Components?

    There are some good third party software components out there, that have been developed over many years.

    Over the years, I personally have used www.devexpress.com with both Winforms and ASP.NET Webforms, www.telerik.com on ASP.NET Webforms and www.obout.com on ASP.NET Webforms.

    Let me make the distinction between components and tools. This post is about components that you include in your software. Tools such as Resharper from JetBrains, JustDecompile, Fiddler and JustTrace from Telerik are excellent and highly recommended. In fact I don’t know what I would do without them.

    Should you use third party software components? Well it depends.

    If you are using Winforms and to some extent WPF, then considering third party tools to help with the UI layer is a good thing, because you will massively improve your Winforms user interface. DevExpress in particular has a very rich set of components for the UI, although there is no reason why you can’t mix and match and use components from a number of suppliers if your budget allows.

    If you are using ASP.NET, then the picture is less clear. My personal preference are client side UI components such as jQuery UI and Kendo UI used with ASP.NET MVC. If you are using ASP.NET MVC it is very easy to create a good usable layered architecture using conventions from MVC, and your own design in other layers, perhaps with the help of Microsoft Entity Framework or Telerik DataAccess to do your object relational mapping.

    For ASP.NET web development, I would highly recommend that you learn how to create code WITHOUT using the server side third party components first of all, so that you understand fully the problem you are solving and can work out what the benefits are in detail and if they outweigh the investment in money and time learning these tools.

    Also, you should not let these tools into layers other than the UI layer without very careful consideration, especially if you don’t fully understand what they are doing. Assuming your application is more than just a small app with a couple of pages in it, its important that you get your architecture right and keep to its design principles without having third party tools muddy your waters.

    Finally, some of these tool manufacturers DON’T WRITE REAL APPS. They employ bright young people straight from university who have no idea how to write anything more than a whizz bang very flash example that might be impossible to include in your app without destroying your own elegant, readable design and the principles of your own architecture. Not only that, they are closed companies in that they don’t want you to know how to write apps without them because I’m sure they fear that you might not use their services if you knew how to do it without them (nothing could be further from reality in my view).

    These are the things you should really be thinking about, not just the time you think you might save by using third party components.

    I hope to cover this subject more in future posts on software architecture and design.