Posts Tagged ‘Code’


Recently I learnt about an alarming situation regarding a system rolled out in a utility service for rendering emergency help to public users. It is quite imaginable that similar conditions may be prevailing in number of other towns in various utility operations.


It appears that these systems are not developed centrally under controlled processes as one would have thought, but more as local initiatives. And these are developed with the help of freelancers or part-time professionals and not with employees on rolls. This is understandable for reasons of skills shortage and also costs involved. And dealing with an individual developer is a lot easier than dealing with a service provider company especially for carrying out changes. In this mode of development, the changes, more often than not, are occasioned by requirements originally missed out due to lax ways of specifying rather than requirements evolving over usage. So it is not unusual to see a spate of changes lined up soon after the roll-out.


The code rolled out in the production server does not match with the code on the development server. Perhaps some code pieces are lying somewhere on the development server not easily traceable, or they are lost, or some changes were made directly on the production server. The seriousness of the situation has not sunk in yet. The ability to maintain and enhance the software is seriously compromised. For those of us who have been in this business long enough, this is not unusual. But what is scary is these are public-facing applications rolled out in the field, whose malfunction could cause personal injury or, worse, loss of life.


Further, there is no concept of version control or a sand-box for thorough testing before roll-out. It is not known if the system is piloted first before the full roll-out to iron out wrinkles.


As if this is not enough, I understood the freelancer has gone away for reasons not known. May be it was a cost cutting measure or the freelancer hiked his fees or he had to put distance between himself and the mess that was created (may not be entirely his doing). Needless to say there has been no formal hand-over process. When even the live-code inventory is incomplete, code or system documentation is too much to ask.


Into this scenario, the freelancer’s replacement walks in. Can you imagine his/her plight? And, there is a pile of pending enhancement requests waiting for him/her to take up right away. What it takes to maintain software is not always appreciated. What is at stake is not the individual’s performance, but safety of public users for whom the system is in operation.


Since public safety is involved, it is important that some minimal norms are enforced for developing and subsequently maintaining these systems and, the compliance to these norms are audited from time to time. May be these norms and audits are already an established practice in some  geographies.


This is not a call against freelancers who deliver great value, flexibility and responsiveness (and skills too) required by users whose requirement for software development is light and sporadic. It is a call for controlled processes for developing software especially for moderate-to-high impact applications.


Processes must be recognized as a mandatory piece of any scenario wherein software is developed or used for a serious application. The processes are not meant only for the developers; importantly, they also discipline the users (not the end-using public) who commission the developers and whose laxity is also often the root cause of the ensuing mess. It follows that both the developers and the users must be educated on the processes to be followed.


Of course, the processes must be right-sized to suit the customer and the application. Else, they could enormously slow down the software development efforts. Admittedly, right-sizing processes may not be a trivial exercise. Further, it is not required to induct a full set of processes which could be quite intimidating for a light-load user. It is sufficient to implement some key processes at a level of simplicity that serves the purpose. 


This could be done with some minimal professional help. May be there are sources from which it is possible to buy right-sized processes; and, get the freelancers to follow them.


On part of the software service providers, there is money on the table for those who come up with innovative models to develop and service systems for these light-load customers at affordable TCO without compromising on the norms. 


Of course, an off-the-shelf package solution significantly mitigates the risks and must be strongly considered as a solution over custom development.

Read Full Post »

Today the amount of code developed per project has dropped dramatically from the days of Cobol. Microsoft routinely bundles in a few thousand pre-coded classes along with its Dot Net Framework in the attempt to reduce coding largely to drag and drop. Organizations all over have bought into the benefits of adapting ready packaged solutions over custom developed software. But coding is not yet an ‘endangered’ job and is not likely to fade away anytime soon. So standards in coding continue to be relevant at least for now.

Many coders are young freshmen from college. They may not yet appreciate how coding realizes, on the ground, architectural objectives set out for the software. Coding standards, for them, are much simpler ready recipe to follow without deep knowledge of these architectural objectives. Adherence to the standards thus mitigates the risk of inexperience or lack of higher-order knowledge.

There is a second source of risk. Today, code is no longer monolithic – it resides all over the place, inside the browser, server pages, beans, cgi code, apps server, sql procedures, xml, css, etc. These are different technologies, each commanding its own best practices. You tickle anyone of them in the wrong place you are in for some grief. For accomplishing a small function, code from many of these fragmented technologies must be threaded together. Things never got simpler under the hood! In such a mixed-up scenario, pre-packaged wisdom by way of standards or best practices reduces the risk of inappropriately using these technologies.

I still recall from past how someone in a remote support team, working on an emergency patch, caused a blood bath by writing a short sql snippet disregarding some set norms, that inadvertently wiped out data partially from the end-user’s production server.

OK, that’s enough of reasons to have standards and best practices. So, what’s the point?

When I interview developers, I quiz them on coding standards. Most organizations have coding standards that run into several pages. We seriously think that any developer allows himself to be guided by these pages of do’s and don’ts every time he keys in a snippet of code? Fortunately checking adherence appears to be more manageable with tools available now which can zip thru developed code against a few hundred coding rules and spew out the violations. The rules could even be customized. But can you imagine the effort involved in removing these violations? The only way to operationalize these voluminous standards for real would be to put together a tool that would clean up the code generated by the developer automatically or in an assisted mode or have the IDE enforce these standards while the code is being developed. To expect the developer to manually adhere to the standards is impractical. If the organization’s Quality System or the Process Model expects this adherence or if someone out there claims all these pages of standards are scrupulously adhered to in the manually written code…

There is another serious angle to these voluminous standards. These standards rarely have architectural attributes as one of the keys. So when I ask ‘What parts of your organization’s coding standards help you to develop an application with very low number of defects?’ most often candidates have heard it for the first time. We all know that an application cannot be developed with equal emphasis on some 20+ architectural attributes. The question of classifying the standards by architectural attributes and prioritizing them for a given application is real.

It is common to find the standards keyed by the subsystem covered. Of all standards, those covering the database subsystem are most crucial because any damage thru incorrect coding in those parts could be permanent, affecting large number of users and recovery painful. With most other subsystems, the worst case may be an aborted user session. External Systems, it is assumed, are capable of rejecting wrong usages.

It would be interesting to contemplate on other possible keys (technology is another obvious candidate).

Later we will look at some real life examples of what goes into the coding standards and how to put some real bite into them.

Read Full Post »