Warning signs...
This entry is addressed to executives and investors of software companies. Why? Because you have the biggest stake in long-term health of your company. And given how common it is to find dyfunctional software development organizations, chances are that things at your company aren't exactly in the pink.
Some red flags to alert you that things aren't necessarily poised for success in the long run:
(1) Programmers tell you that the code makes their heads hurt, and they don't think the code they are working on has long-term viability.
(2) Releases can't seem to get to FCS on time, and without major bugs popping up at the last minute.
(3) Service packs need to be recalled or patched regularly.
(4) Programmers are expected to put in long hours, in particular on weekends.
The reality of software development, some might say. Not necessarily so.
First, code that makes programmers's heads hurt is a huge liability. This means that things are barely, if at all, under control. If you're company is a start-up, then you are really going to a bad place in a hurry. If your company is an established leader in a market, you're toying with the prospect of not being able to respond quickly to shifts in the competitive landscape.
To be able to create new features and fix bugs, programmers need to have clear code. They can't work effectively with code which is all but incomprehensible, filled with thousands of lines of cleverly-implemented and poorly-formatted 'if' statements that take a genius to follow. Most of the time, in these cases, programmers will privately question how much longer they'll be able to do anything with the code.
There is no quick fix to this problem, but there is a remedy which will move things towards professionally-engineered software and a safer place for your company. The remedy is a practice called refactoring, which is the common sense practice of tidying up the code when it starts to become unclear. The best time to do this is when the logic behind the code is still fresh in the mind of the programmer who thought up the logic and wrote the code. Lacking that, programmers should regularly be assigned projects to refresh their memories and refactor sections of code which cause migraines.
For releases which can't get out on time, and which seem to be hobbled by surprise bugs on the eve of release, there is a strong likelihood that the projects which contributed code to the release were never properly planned. What I mean by "planned" is not the "big upfront design and gantt chart", but rather an initial pass to identify all of the tasks each project involves to get a sense of how much time is required and to identify risks and pitfalls, and then regular updates by the programmer to keep the plan current. This requires a bit of effort and discipline at first, but programmers who use this practice (including myself) find our projects wind down in quite a boring, unexciting and on-time fashion. This practice can be taught, and is easier to learn if programmers are provided with appropriate (read: easy-to-use) planning tools.
For service packs which cause major embarrassment, there is a strong likelihood that the thinking behind the code has faded away, and programmers are "reverse-engineering" the thinking from code (which often makes their head hurt), and they make mistakes in the process. These conceptual mistakes lead to programming errors, and often large problems in service packs.
A solution for this is to introduce into the software development organization one or more technically-savvy and articulate people who interview developers about the thinking behind their code. The results of these interviews are incorporated into the source code in some convenient fashion (perhaps with Doxygen) to provide the next programmer to work on the code with the explicitly-stated thinking of the last programmer who wrote the code. Having programmers add this commentary themselves has routinely fallen flat because programmers generally don't like to write, can't write articulately, and have a hard time making sure they have addressed all of the relevant questions. An independent interviewer will naturally drill down in the necessary places, and will hopefully will be able to articulate the relevant information in a way that quickly gets the next programmer up to speed.
On top of having to "reverse-engineer" thinking from code, programmers probably aren't communicating with the testing staff about exactly what needs to be tested, which is why a service pack goes out with major problems. This problem which can be remedied by providing a mechanism for programmers to provide testers with a basic test plan for each change to the software. It sounds like a lot of extra work that will slow the programmers down, but remember, this is about getting a quality product out to your customers. Just because programmers don't want to be disciplined is no reason to majorly inconvenience your customers and embarrass your company (not to mention lose profits). Programmers won't natually become disciplined without regular training and coaching, though, so it is your responsibility to introduce this into your software development culture.
Long hours and weekends for programmers is a sign of a number of problems. First, it is very likely that projects were not thought through thoroughly enough to validate time estimates. There was probably a lot of wishful thinking, and not too much consideration of real risks. The remedy for this problem is the task planning I talked about above for getting releases out on time.
Secondly, it might be that the code is making the programmers' heads hurt, and they're having a hard time reconstructing the thinking of the previous programmers. Clearly, if the previous programmers had been interviewed and their thinking documented, and they were required to leave the code in a clear state for the next programmers, the amount of time new programmers need to spend to accomplish their work would be significantly less.
Third, the morale of the programmers is likely eroding, and there is a more-than-healthy amount of tension with management. Programmers no longer make their best efforts and cut corners, which sets the stage for bugs which appear only after the software is released, and code which make programmers' heads hurt. It's great to have a team which works hard, but when the work begins to erode your programming staff, you're actually damaging your company. Many companies have faded from prominence for exactly this reason.
Experience has shown it is counterproductive to program for more than six hours per day. Programming is an activity of the human mind, not a machine. The human mind needs to refreshed and enriched. If forced to spend its existence in a monotonic state of brute force programming and bug fixing, its effectiveness erodes. People burn out. People move on to other jobs (often before spending time with an interviewer who divines and documents the thinking behind their code).
There are other red flags which I will write about in coming segments, but don't wait. Take a few minutes to find out from your programmers where things stand, and put in place measures which will vastly increase the long-term health of your software source code and programming organization.
Some red flags to alert you that things aren't necessarily poised for success in the long run:
(1) Programmers tell you that the code makes their heads hurt, and they don't think the code they are working on has long-term viability.
(2) Releases can't seem to get to FCS on time, and without major bugs popping up at the last minute.
(3) Service packs need to be recalled or patched regularly.
(4) Programmers are expected to put in long hours, in particular on weekends.
The reality of software development, some might say. Not necessarily so.
First, code that makes programmers's heads hurt is a huge liability. This means that things are barely, if at all, under control. If you're company is a start-up, then you are really going to a bad place in a hurry. If your company is an established leader in a market, you're toying with the prospect of not being able to respond quickly to shifts in the competitive landscape.
To be able to create new features and fix bugs, programmers need to have clear code. They can't work effectively with code which is all but incomprehensible, filled with thousands of lines of cleverly-implemented and poorly-formatted 'if' statements that take a genius to follow. Most of the time, in these cases, programmers will privately question how much longer they'll be able to do anything with the code.
There is no quick fix to this problem, but there is a remedy which will move things towards professionally-engineered software and a safer place for your company. The remedy is a practice called refactoring, which is the common sense practice of tidying up the code when it starts to become unclear. The best time to do this is when the logic behind the code is still fresh in the mind of the programmer who thought up the logic and wrote the code. Lacking that, programmers should regularly be assigned projects to refresh their memories and refactor sections of code which cause migraines.
For releases which can't get out on time, and which seem to be hobbled by surprise bugs on the eve of release, there is a strong likelihood that the projects which contributed code to the release were never properly planned. What I mean by "planned" is not the "big upfront design and gantt chart", but rather an initial pass to identify all of the tasks each project involves to get a sense of how much time is required and to identify risks and pitfalls, and then regular updates by the programmer to keep the plan current. This requires a bit of effort and discipline at first, but programmers who use this practice (including myself) find our projects wind down in quite a boring, unexciting and on-time fashion. This practice can be taught, and is easier to learn if programmers are provided with appropriate (read: easy-to-use) planning tools.
For service packs which cause major embarrassment, there is a strong likelihood that the thinking behind the code has faded away, and programmers are "reverse-engineering" the thinking from code (which often makes their head hurt), and they make mistakes in the process. These conceptual mistakes lead to programming errors, and often large problems in service packs.
A solution for this is to introduce into the software development organization one or more technically-savvy and articulate people who interview developers about the thinking behind their code. The results of these interviews are incorporated into the source code in some convenient fashion (perhaps with Doxygen) to provide the next programmer to work on the code with the explicitly-stated thinking of the last programmer who wrote the code. Having programmers add this commentary themselves has routinely fallen flat because programmers generally don't like to write, can't write articulately, and have a hard time making sure they have addressed all of the relevant questions. An independent interviewer will naturally drill down in the necessary places, and will hopefully will be able to articulate the relevant information in a way that quickly gets the next programmer up to speed.
On top of having to "reverse-engineer" thinking from code, programmers probably aren't communicating with the testing staff about exactly what needs to be tested, which is why a service pack goes out with major problems. This problem which can be remedied by providing a mechanism for programmers to provide testers with a basic test plan for each change to the software. It sounds like a lot of extra work that will slow the programmers down, but remember, this is about getting a quality product out to your customers. Just because programmers don't want to be disciplined is no reason to majorly inconvenience your customers and embarrass your company (not to mention lose profits). Programmers won't natually become disciplined without regular training and coaching, though, so it is your responsibility to introduce this into your software development culture.
Long hours and weekends for programmers is a sign of a number of problems. First, it is very likely that projects were not thought through thoroughly enough to validate time estimates. There was probably a lot of wishful thinking, and not too much consideration of real risks. The remedy for this problem is the task planning I talked about above for getting releases out on time.
Secondly, it might be that the code is making the programmers' heads hurt, and they're having a hard time reconstructing the thinking of the previous programmers. Clearly, if the previous programmers had been interviewed and their thinking documented, and they were required to leave the code in a clear state for the next programmers, the amount of time new programmers need to spend to accomplish their work would be significantly less.
Third, the morale of the programmers is likely eroding, and there is a more-than-healthy amount of tension with management. Programmers no longer make their best efforts and cut corners, which sets the stage for bugs which appear only after the software is released, and code which make programmers' heads hurt. It's great to have a team which works hard, but when the work begins to erode your programming staff, you're actually damaging your company. Many companies have faded from prominence for exactly this reason.
Experience has shown it is counterproductive to program for more than six hours per day. Programming is an activity of the human mind, not a machine. The human mind needs to refreshed and enriched. If forced to spend its existence in a monotonic state of brute force programming and bug fixing, its effectiveness erodes. People burn out. People move on to other jobs (often before spending time with an interviewer who divines and documents the thinking behind their code).
There are other red flags which I will write about in coming segments, but don't wait. Take a few minutes to find out from your programmers where things stand, and put in place measures which will vastly increase the long-term health of your software source code and programming organization.
posted by John Keklak at
8:59 AM
0 Comments:
Post a Comment
<< Home