I have been thinking about longevity of software, how it ages and eventually dies. Many of the software that was around while I was baby footing in this industry is no longer around or has come up with newer versions that resemble to the original only in name. Is it possible to write a truly magnificent piece of software that can live forever without being a recluse? If we realistically don’t expect our software to live forever, what are we doing about it?
Is it possible to design for the future in advance? Unless hit by a bus tomorrow, I can venture a fair guess about what will happen to me at most 1 year from now, not more than that. Then how can we design a piece of software to work for even 5 years. Do we even think about how many years a piece of software will be used while designing?
There is music, films, paintings and buildings that last for a really long time, but the average life of software maybe 5 years (wild guess). There are too many parameters changing in software usage. Programming languages, operating systems and hardware is still changing along with maturity of software users, competition in the market, new innovative ways to do business and systems to support it, more and more automation. Internet is becoming part of routine life. A system designed 5 years back to automate a manual process is a called a legacy system now. Sophistication of requirements increase with time – process automation was the original requirement. Now same users want analytics, modeling and personalization of systems.
Business empowerment is another theme that is driving system changes. Users won’t want IT involvement in modifying values in a list of values or adding a field to a page or creating a custom report. Combined with Sarbanes-Oxley and Change Management processes, if you force business users to submit a change request and ask them to go through a set of approvals etc to add a field to a data entry page, then it will be frustrating. On the other hand I don’t think it is possible to make a system completely configurable so that it can sustain itself. At least that is not practical if it is for use by one organization, not a full-fledged product.
What I established so far is that too many parameters change over time – business, sophistication of users and technology. It is not cost effective to create a truly flexible system for use by internal organization. It is difficult to predict future. But is there anything that can be done to extend the life of software? Couple of things comes to mind – routine checkups, constant exercise to remain healthy and accommodate changing needs. I remember something that I studied in school economics – with education, need of people change.
If a request for a similar type of change comes in 10 times a year, it is high time to make the think about a way to reduce the IT dependency in doing that. Alleviate the heartache by giving more control to users. At the same time, don’t expect to cut off IT completely – the system may become like an abandoned house and weeds may start to grow up the roof. With this, my intention is not to make a case for livelihood of IT department.
In conclusion, systems are not immortal, it will age and there should be enough nourishment to keep it going strong and keep up with the changing world.
problems and solutions
A quote on a manager’s door in my office – “Don’t come in with problems. I want solutions”. I think a beginner will go to his boss with problems and would not have thought about solutions at all. Next level is thinking about options to solve and the pros and cons in choosing any of the options before even going to the manager. You cannot expect the manager to solve every problem. Anyway the first thing he will say is “okay, I hear your problem. So what can we do about it?”, so better be prepared for that. Better yet, identify the best solution and implement and then inform the manager. You have to inform your boss anyway – if you find the problem, analyze it and fix it and nobody knows about it, still you will be on losing end since nobody will ever know how good you are. Even the next level will be anticipating problems and fixing it before it can surface.
How to take up maintenance of an existing software application?
Software development is not always about developing an exciting new application. There are situations where you need to get into application maintenance or enhance an existing application. I never thought I would write a “How to...” or “Art of...” article, but here it is. It is not in any particular order, just things that I may have done in maintenance projects.
1. Suspend judgment: - It is a universal fact that we fear or suspect the unknown. Unless we can see it, touch it and make sure that it is not dangerous, we may withdraw from things without even putting up a fight for it. There are systems developed over many years and it may seem like an uphill task to take up maintenance of such application. I like the phrase “suspend judgment” – be it meeting a new person, watching a movie, reading a book or getting to know a new application. Suspend judgment at least until you can confidently evaluate whether you like it.
2. Persistence: - Another phrase that is sticking with me is “Things Take Time” – it takes time to get to know people, I have loved some music after listening to it for tenth time. As it says, “Long term relationships take the longest time to build.” It is like a tough puzzle – you can take a shot at it, then go watch a movie, forget all about it and then come back to it. We might be pleasantly surprised to find new ways of looking at things. It is an amusing analogy to compare getting to know a person and getting to know an application. I may not be over enthusiastic about an application in the beginning and usually observe the situation carefully until I tune into the same wavelength.
3. Poke at it: - Like a kid trying out a new addition to his world, poke at the application from all possible angles. Get to know a bit from technical architecture and you apply that to understand business behind the application some more and the circle enhances itself. This need not be very structured. If you get a lot of theory on swimming like how to breathe through mouth while flapping the feet, tilt the head and continue to move forward with an effortless action, the task will look more difficult than it actually is.
4. Find ways to find things: - I think this is an important step in being self sufficient with an application. I need to know how to get into application, documents, database and servers. Give me this much information and I can slowly and steadily learn the application. If someone asks, at least I can reply, “I can check and get back to you”.
5. Dig into it: - Once you know your way around, you can go further into the maze of application. Will I have enough inspiration to do this on my own? I am basically a lazy person and I may not take the initiative to read the code just on my own. A question from somebody about the working of specific feature of the software is a good enough motivator for me – then I can go in with the single objective of finding the answer and learn a lot on the way.
6. Document it: - documentation is painful, but I have always found it easy to do it while I am enjoying the feeling of discovery. Documentation will be boring once you know it all. I write things down usually to organize my own thoughts. I used to study in an odd way during college – I used to create notes, hand written (not scribble, but properly with margins and in good handwriting), while reading about something. This was my way to cut through the clutter in textbooks. I may never refer these notes (I might be making these notes just the day before the exam), but it used to make things clear in my mind. So creating a rudimentary document for my own reference may be a way to understand things better and often you get more questions while writing down. When you have everything in your head, maybe the some of the questions get pushed to the fringe and we would just assume that somehow these things will happen, but while writing it down in black and white, you just cannot bypass these nagging questions.
7. Get your feet wet: - Yet another phrase that I carry around “we are afraid to call ourselves experts”. We are afraid to say that when the knowledge is superficial. We think we can do something and it is simple, but have never done it, so can’t say for sure that it can be done. Try to do it, you will find obstacles that you never knew existed and by solving it, you will learn a lot.
8. Talk about it: - Discussing with team members or with sometimes anyone who may listen to you is another way of validating the assumptions. Ever had a feeling that as you speak you connect dots and come up with ideas that you have never thought of before consciously?
9. Code is the ultimate truth: - Find ways to get to the code. Yet another of my catchphrases. As an aside, I think these kinds of phrases become your guiding principles in life. I might have all my assumptions and ideas about what a system does, but if I can read the code, then that is the ultimate truth about what it really does.
10. How to debug: - I see debugging as one of the perks in software development. It presents natural challenges, kind of like puzzles in daily newspaper. But to enjoy it, one should use right set of tools, know where to look and have patience to keep looking for bits that could be helpful. In maintenance mode, knowing how to debug faster is a matter of survival as well.
1. Suspend judgment: - It is a universal fact that we fear or suspect the unknown. Unless we can see it, touch it and make sure that it is not dangerous, we may withdraw from things without even putting up a fight for it. There are systems developed over many years and it may seem like an uphill task to take up maintenance of such application. I like the phrase “suspend judgment” – be it meeting a new person, watching a movie, reading a book or getting to know a new application. Suspend judgment at least until you can confidently evaluate whether you like it.
2. Persistence: - Another phrase that is sticking with me is “Things Take Time” – it takes time to get to know people, I have loved some music after listening to it for tenth time. As it says, “Long term relationships take the longest time to build.” It is like a tough puzzle – you can take a shot at it, then go watch a movie, forget all about it and then come back to it. We might be pleasantly surprised to find new ways of looking at things. It is an amusing analogy to compare getting to know a person and getting to know an application. I may not be over enthusiastic about an application in the beginning and usually observe the situation carefully until I tune into the same wavelength.
3. Poke at it: - Like a kid trying out a new addition to his world, poke at the application from all possible angles. Get to know a bit from technical architecture and you apply that to understand business behind the application some more and the circle enhances itself. This need not be very structured. If you get a lot of theory on swimming like how to breathe through mouth while flapping the feet, tilt the head and continue to move forward with an effortless action, the task will look more difficult than it actually is.
4. Find ways to find things: - I think this is an important step in being self sufficient with an application. I need to know how to get into application, documents, database and servers. Give me this much information and I can slowly and steadily learn the application. If someone asks, at least I can reply, “I can check and get back to you”.
5. Dig into it: - Once you know your way around, you can go further into the maze of application. Will I have enough inspiration to do this on my own? I am basically a lazy person and I may not take the initiative to read the code just on my own. A question from somebody about the working of specific feature of the software is a good enough motivator for me – then I can go in with the single objective of finding the answer and learn a lot on the way.
6. Document it: - documentation is painful, but I have always found it easy to do it while I am enjoying the feeling of discovery. Documentation will be boring once you know it all. I write things down usually to organize my own thoughts. I used to study in an odd way during college – I used to create notes, hand written (not scribble, but properly with margins and in good handwriting), while reading about something. This was my way to cut through the clutter in textbooks. I may never refer these notes (I might be making these notes just the day before the exam), but it used to make things clear in my mind. So creating a rudimentary document for my own reference may be a way to understand things better and often you get more questions while writing down. When you have everything in your head, maybe the some of the questions get pushed to the fringe and we would just assume that somehow these things will happen, but while writing it down in black and white, you just cannot bypass these nagging questions.
7. Get your feet wet: - Yet another phrase that I carry around “we are afraid to call ourselves experts”. We are afraid to say that when the knowledge is superficial. We think we can do something and it is simple, but have never done it, so can’t say for sure that it can be done. Try to do it, you will find obstacles that you never knew existed and by solving it, you will learn a lot.
8. Talk about it: - Discussing with team members or with sometimes anyone who may listen to you is another way of validating the assumptions. Ever had a feeling that as you speak you connect dots and come up with ideas that you have never thought of before consciously?
9. Code is the ultimate truth: - Find ways to get to the code. Yet another of my catchphrases. As an aside, I think these kinds of phrases become your guiding principles in life. I might have all my assumptions and ideas about what a system does, but if I can read the code, then that is the ultimate truth about what it really does.
10. How to debug: - I see debugging as one of the perks in software development. It presents natural challenges, kind of like puzzles in daily newspaper. But to enjoy it, one should use right set of tools, know where to look and have patience to keep looking for bits that could be helpful. In maintenance mode, knowing how to debug faster is a matter of survival as well.
Subscribe to:
Posts (Atom)
weekly notes, wk 15 / 2024
I wanted to capture some memories, atleast so that it comes in google photos a few years later as a reminder. I was in London in the past we...
