Upgrading your code or a 3rd party app. Is there a reliable way?

In programming there is a constant debate about how to design an application. Whether it should be object orientated, should test cases be included. Lost of questions and everyone has an opinion.

I don't have a computer science degree or background I have a sport science one. I taught myself to program and learnt very much on the job. So I don't claim to have all the knowledge. What I have done is learn from those who do and used the web particularly to look into these debates to see what history and current best practices teach us. 

An age old problem I've come across is how to move from an old system to a new one or how to rely on a 3rd party system while ensure the application you present to the world maintains the quality and standards you have built a reputation on. 

As is usual with me I have generally found a way to do both the above by finding a model that provides both options. It's not a highly technical plan because that would only work on specific operating systems and programming languages etc. It's more of a theoretical one that poses some questions and answers that fit what I care about most. That's efficiency, stability coordination and other such words. 

Ok that's a bit arty farts. What I'm really getting at is that it's common to want to update your systems and find that's going to be a nightmare and costly. it's better to have planned for this in advance and to be able to regularly keep up with, and plan for, best practice. To have well defined general approaches to keeping up to date regardless of the technology you're working with. 

I do this first by asking questions. Laymans questions that come from the idea that applications and solutions are built by humans for humans. They are not designed for machines. They may connect to machines but it's to help humans that these solutions exist. 

So if you have an application that you know is going to need upgrading how would you go about it?

I always do it slowly. I look at the patterns that are inherent in what it does. What kind of tasks does it do regularly and does it need to be good at. I then begin a process of changing from within. I create reusable pieces of code and tiny solutions that cater for these specific repeated patterns. I start to weave these into the code, first tidying things up a little then as this new code starts to do more and more of the work I find it becomes possible to make larger changes because the new code is making things easier. it sounds too easy but from experience if you plan for reuse, and I've found I'm quite aggressive about reuse I think it's crucial, then you'll find the code you have to write and work you have to do to achieve new qoals becomes easier and easier. 

Early on particularly I do this work in such a way that users don't actually see any change. Apart from things slowly getting faster. I care about build api's which are common ways for applications to talk to each other and within themselves. so I make sure each set of code that gets replaced can be used in the same way. It just does it better. This isn't the rule but if I do this I often do. Particularly with the user interface. I often prefer to improve the underlying code, the infrastructure, before working on the interface because this is what most customers care about. So leaving it leaves me free to get the nuts and bolts right. 

The approach I use is what I've seen builders do when renovating a building. They don't always knock it down and start again. At the OU they recently renovated the buildings the BBC used to broadcast from. I heard that the building where listed so they couldn't knock them down. I'm not certain that's true because they removed everything just left the walls and ceilings. That implies to me that it just costs too much to completely demolish a building. That's also what I've heard from engineers. If the walls and ceilings are fundamentally sound and planning permission is not required, since the building already exists (politically that concept is key as well as legally) much cheaper and quicker to use what's already in place and make the best of it and get good at making the best of it. Mainly because things are always improving so better to be an expert at taking something and improving it than always needing a fresh starting point. that in itself is a major limitation that can be costly. 

So if an application were a building and the application was still being used, much like a building that's still being inhabited. I would get good at doing important work without forcing people to stop their work. there are many examples you can use in building that compare with what I use. If you need to change a key part of the system that can only be changed when no one is using it then the solution depends on how critical it is, how long you've got to do it and many other factors. 

I pick from a long list of options I have to suit the situation:

• Put code or solutions alongside that to be replaced and a switch that can easily be flicked. Use this approach throughout the system so that you can always switch back to the original code if you need. In case your upgrade doesn't quite work
• have a decent test bed. Figure out the essential tests that you need to run and have a system that can support this. Very quickly you'll realise that the most important question is 'is each part of the system doing what it should do?'. Tests are the only reliabel way of doing this. The more critical the change you're making the more the tests are required.
• where possible build off site, or off your code base and drop in the fix when finished. All manufacturing has moved to this approach of easily switchable components, from cars to ships (I watched a documentary about the Queen Mary 2 showing how parts were built separately then stitched together) to buildings. Each individual part can then be tested thoroughly before being stitched into the whole. Software development is no different. There are ways to do this. If you don't know them then learn them. 
• Find ways to organise things better. from the code itself to the files and application structure. this makes it easier to find problems, to find code to know what's new code and what's new. 

There are plenty more techniques and ideas I've come across. Some just common sense to me, others I've found from other people. Just thought I'd start putting them down here. To do exactly the kind of thing I'm recommending. I always start to work towards a standard. I either find one I like or generate my own. Standards and patterns go together and that's essentially what I work to. Once I start identifying patterns I start seeing quickly how to reuse a lot of the work I do to save time while improving quality Standards are about applying the patterns regularly and making it easy to do so. 

I see that I haven't covered how I work with 3rd party applications. In truth I use the same list as I was creating above. With the extra caveat that I like to distance myself from the application itself. I like to write a wrapper or set of wrappers around the 3rd party software so that I have my own layer inbetween. Every application that connects to this 3rd party application goes through the layer I have built. This way the 3rd part application can change but all I've got to do is change my layer to work with these new changes. 

Obviously it's not always this easy but with time and care it often is. More than once I've done a major upgrade but, due to these small changes and the stability layer I've added, the systems that use the software have worked fine. I've used the tests I always run to see what's stopped working after the upgrade. this has told me what work I need to do. then each time I've completed some fixes I run the tests again to see what's left to do. Normally I can fix the stability layer so that the existing applications can still work unchanged. Often any important changes needed to support the upgraded 3rd part application can be built into the stability layer at some point leaving the dependent applications unchanged. If there are changes required then atleast these are minimised.

I say stability layer but tin practice it's just a set of files that store my code as opposed to the third party code. Where appropriate I mnay tie these into the 3rd party code itself. the important thing is to be easy to distinguish the difference. If you can't see easily what's yours or not then you'll have problems sooner or later.