There are big differences between system development in a maintenance system compared to working with new development. The 3 major differences, I wou

There are big differences between system development in a maintenance system compared to working with new development.

The 3 major differences, I would say, is time, system knowledge, and version handling.

In this article I aim to discuss these differences a bit.
But to start with... I think it is crucial to aknowledge that there are great differences.
And also crucial to always think about the maintenance of the system when developing it.
For example, the choice of technique to use in the system should be synced so it matches the people who most likely will maintain the system.
One need to ask - who may maintain this system 1 year ahead and who after 5-10 years ahead? How will this system be running then?
What are the technical competencies of the people who will maintain the system.

Many times a system developer in a maintenance team is a mix of a programmer and functional expert.
Probably that person maintain not just one system but several ones. And several big ones.
This developer may not keep up to date with all the latest teqniques for understandable reasons.
We don't want stagnation - we need to move forward with techniques and be in the future.
But we should be aware not to use too many new and small techniques - especially if maintenance will be by just 1-2 persons.

When designing the code - we should also think about maintenance. Develop for maintenance.
Are we creating a system that easy can be debugged? Easy can be regression tested?
Are we making the system architecture intuitive, so it will be easy to find which functionality is implemented by which class/classes.
Do we really need so many modules? Do we really need so many interfaces? Do we need recursive loops or can we write it longer but easier to debug and understand?
Do we need all these innerclasses? They may be smooth and fit well into the object thinking - but maybe they are more difficult to find/debug?

Ofcourse, with Behavour driven development and test driven development - we are very close to the goal of getting system that are easy to maintain and develop further!

So now - my reflections around the issues "Time", "System knowledge" and "Version handling":

Time:
In new development teams - you have deadlines to look after. Nemas problemas.
In maintenance systems, you have to make severe problem fixes in modules you have never heard about in a couple of hours. That is problemas.
The question is - How to secure good and fast fixes for severe production problems?

One option is making a a quick temporary fix - that allows some time to breethe and figure out a more well designed programmatic fix to the problem.
In any case you need to know about the systems full functionality and design in order to figure out where any fix best should be placed.
You also need to understand the implication of the fix.This leads me to the second difference...

System knowledge. Or rather how to get access to system knowledge, in a quick way.
When new systems are built, system knowledge is found all around you. The architect or programmer of a certain module, may sit next to you.
New systems are usually built by a large team of a bunch of clever intelligent programmers. They use all their smartness. They prefer to use new improved technology that will be flexible and suit the future. Some of the team may stay a while - but then as the system goes into production and stabilises, they diminish. Left is maybe just 1 or 2 persons. 1-2 people will now support a complex system, maybe built by 10 people over 1 years time. Not an easy task!

Even if the people working with maintenace hopefully have been part of the development, they will probably not know about all the clever smart things implemented.
Many times it is the most smart programmatic solutions that are most difficult to maintain, i.e. to understand and make changes within.

Usually, all further development of the system, now made by the maintenance team - are just focused around certain bits of the system.
So what is needed to quick get access to knowledge about the rest of the system, when it start to fail?

Solution is mainly.... Documenatation! Yes, documentation.

Since our head can't have everything, and we may die - and then somebody else needs to take over... The best is to have a single point of start where we quick can find links to all documents we need.
For example, its perfect with a wiki that links us right.

From the top of my head I would say the following piece of documentation/information to be stored, is definetely needed.

• Location of things - list of server names, log locations, applications and batch jobs locations - for all various levels of environments.
• Roles documentation. Who is responsible for what, Who can I call to quick get answers of functionality etc. Needs to be accessible by all and updated always.
  (Ofcourse, the people having a role, must know that they have that role, this is not always the case.).
• Architectural descisions doc - will answer "what are the reasons for why this was built like this". Should only be used when a descision actually is made.
  A reason can be like: "we decided to keep module A and B separate since there are discussions of maybe in the future replacing module B with XXX".
  If we know the reason - then we can evaluate if that reason still seems valid.
  This may have a huge impact on how the fix may be implemented.
  So - some kind of "architectural descisions" document is very valuable.
  We may remember that regarding module C it was something important to remember but not wat it was.
  With this kind of document, we will remmeber what to remember. .
• A plain old fashioned System documentation. That we need! I don't agree with those who argue for no documentation.
  If the only thing we have in a maintenance team are some java docs and maybe some initial specs...then we need to rethink!
  However, from all really heavy system documents I've read during my years, I would say it is usually just the first two pages that has been of most use.
  So it may as well be enough just to have these 2 pages in a System documentation. But then they need to be real good!

So what do I like in a System doc...? Pictures are good!
-An absolute updated graphical picture of the system and its interactions to other systems, servers and databases.
That gives, as a start, a very good overview of the full system and its external interactions.
- A management summary of the system.
- Lists of all modules and what there main functions are.
Hmmm and so much more... can't take it here...
In any case - documentation outside the system ensures that also non programmers can help in finding the best solution to a fix that needs to be done.
Javadoc is good - but doesn't allow lengthy explanations of a full module. And the question ...which class in the module should have that overview explanation...

• the "Everything" log. My own name for it. Keep a log of all that happens within the system. Mail konversation with client of new requests, complaints from operations regarding time out problems etc.
  Just a very long simple text document where you can cut and paste all from
  a bug report to a mail conversation. In stable systems not much happens. But when it happens it is usually connected with something that you will find in the log.
  A fix was done 9 months ago in module X - and now System B is complaining over data delivered from module X...aha...
  It doesn't get that long - and regurlarly it can be deleted. A log can easy keep 2-3 years of work. It sound a lot, but its not.
  Remember I am talking about stable systems.
• Step by step instructions, are also great to drop here and there! So convenient.
  For example How to build or install module X. Some modules are updated so seldom that there is no knowledge in how to build and deploy them.
• Runtime generated System logs. When production problems, use the generated logs. Make sure you have easy access and full understanding of the generated system logs, in al environments!

The last main difference between new development and maintenance, in this article, is Version handling:

Version handling is seldom of any major importance for new development. You just version handle it in a simple way.
For systems in production, version handling becomes one of the major concerns. And it is also this that annoyingly starts to consume most of the working time.
I.e. this becomes one of the major focuses for all - how to implement new functionality and at the same time maintain old functionality.
How to be able to back. You start to need several paralell versions and you merge branches and codes at appropriate times. You feel like you are more of an administrator than a programmer.
Many times there are also confusions to what release actually is running in production.

With manual installations, human mistakes can be done. Old or wrong releases can be deployed to production.
It is very valuable to ensure an easy way to detect what version of certain code that actually is running.
Can easily be done by logging or other ways of display.

Bla bla...this was my second blog entry ever...are they really supposed to be this long?
....must do something about this...
:-)