Malleability is that property of a material that allows it to be easily shaped. Gold is malleable. Stone is not.
Code should be malleable.
Polymorphism (from the Greek poly meaning "many", and morphe meaning "form, shape") adds to malleability. So do unit tests. Coupling destroys malleability. Cohesion enhances it.
Reluctance to modify code is a sure sign that malleability is being degraded. Attend to it. If it is hard to do now, it is not going to easier on its own.
Code that is not malleable become "Bhoot Banglas". Code that is not malleable is code that is petrified (from the Greek petro for stone). Petrified code leads to petrified code maintainers.
Showing posts with label Software Maintenance. Show all posts
Showing posts with label Software Maintenance. Show all posts
16 January 2014
18 November 2010
Maintaining Software
Lack of maintenance results in a "Bhoot Bangla".
So too for software: RENOVATE it or demolish it. Do not carrying on living with it (or in it).
So too for software: RENOVATE it or demolish it. Do not carrying on living with it (or in it).
17 September 2010
New Toys
Seth's post reminded me of something that I have seen quite often with software developers.
Software developers want to work on new projects. Given the choice between finishing a project and joining a new project, hardly anyone opts for the former. It is in the begining phases, when the product is still "plastic" , that work seems more like play. It is like being in kindergarten. But if all a person does is move from one begining to another, the person will forever remain a beginner - no matter how many projects are put on the resume. The person will forever be in kindergarten.
It is only during the later phases, particularly the maintenance phase, that one gets to realize how things should have been done. That is when learning takes place. That is when one starts to become an expert. It takes time and reflection (hansei). There are no daily thrills. You do not get to play with new toys everyday. You have to study your old toy and learn how it should have been made. Then you can go and make better ones.
Software developers want to work on new projects. Given the choice between finishing a project and joining a new project, hardly anyone opts for the former. It is in the begining phases, when the product is still "plastic" , that work seems more like play. It is like being in kindergarten. But if all a person does is move from one begining to another, the person will forever remain a beginner - no matter how many projects are put on the resume. The person will forever be in kindergarten.
It is only during the later phases, particularly the maintenance phase, that one gets to realize how things should have been done. That is when learning takes place. That is when one starts to become an expert. It takes time and reflection (hansei). There are no daily thrills. You do not get to play with new toys everyday. You have to study your old toy and learn how it should have been made. Then you can go and make better ones.
30 July 2010
What do Embedded Software Engineers Really Do?
A great post by Colin Walls.
What *** really *** resonated with me is what he says about maintenance, “efficient” (quote marks are Collin's) code, keeping it simple, writing code that is readable by non-expert humans, commenting (and then commenting some more).
“Efficient” code is another wolf in a sheep's clothing.
What *** really *** resonated with me is what he says about maintenance, “efficient” (quote marks are Collin's) code, keeping it simple, writing code that is readable by non-expert humans, commenting (and then commenting some more).
“Efficient” code is another wolf in a sheep's clothing.
27 May 2010
Development or Maintenance, What should a fresher choose?
The late Wg Cdr R Raghavan (RR) and I co-founded Ergo Electronics in 1989 and then in 2000, along with some others, co-founded Acme Technologies. He was also my friend and boss. I learnt a lot from him. He will crop up frequently in this blog.
RR had also co-founded Ergo Software Systems in 1986. That was with another person.
He was held in great respect by all software engineers for his software skills. He could quickly diagnose problems in the code, suggest better data structures and module organizations, understand convoluted code and show how it could be simplified. Yet he always maintained that he had written just 4 programs - that too in COBOL! None of the engineers (all working in C) believed him.
After many years of listening to this I asked one of the engineers, "Why do you not ask him how many programs he has read?" The answer: He had lost count. But it is safe to assume it was in the tens of thousands.
RR was one of the founders of the Indian Air Force's computer center. He remained there for about a decade. It was there that he got to read the code for the ICL computer's operating system and other system programs - most in assembly language. He also got to read the application programs written by application developers and learn through their mistakes.
So what should a fresher choose? To me it is a no-brainer. Maintenance - because that is where the greatest opportunity to learn about structure (both good and bad) of programs and data. To learn what make code difficult to maintain. (That is important as any code that is useful will spend most of its life cycle in the maintenance phase. I highly recommend reading Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code
.)
As the saying goes, "Those who do not learn from history, are condemned to repeat it." So too for software engineers who do not learn from others mistakes.
RR had also co-founded Ergo Software Systems in 1986. That was with another person.
He was held in great respect by all software engineers for his software skills. He could quickly diagnose problems in the code, suggest better data structures and module organizations, understand convoluted code and show how it could be simplified. Yet he always maintained that he had written just 4 programs - that too in COBOL! None of the engineers (all working in C) believed him.
After many years of listening to this I asked one of the engineers, "Why do you not ask him how many programs he has read?" The answer: He had lost count. But it is safe to assume it was in the tens of thousands.
RR was one of the founders of the Indian Air Force's computer center. He remained there for about a decade. It was there that he got to read the code for the ICL computer's operating system and other system programs - most in assembly language. He also got to read the application programs written by application developers and learn through their mistakes.
So what should a fresher choose? To me it is a no-brainer. Maintenance - because that is where the greatest opportunity to learn about structure (both good and bad) of programs and data. To learn what make code difficult to maintain. (That is important as any code that is useful will spend most of its life cycle in the maintenance phase. I highly recommend reading Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code
.)As the saying goes, "Those who do not learn from history, are condemned to repeat it." So too for software engineers who do not learn from others mistakes.
Subscribe to:
Posts (Atom)