Monday, 11 June 2012
With availability of skilled programmers on the decline, software development firms need to look at alternate approaches for quality software release. A possible approach being multi-level-programming/ assembly-line programming(just coined)
Engineers based on their expertise could be placed in a particular level/rank, with any software development task to be picked up by the lowest of the level developers. S/he can complete as much as possible based on their expertise and knowledge. The completed software piece at each level is pushed to the next level for further work.
1.) Completion at each level - It should be noted that after each level, the code is functionally expected to be 100% complete.
2.) More than just cleaning - its about tweaking, making the code artsy/beautiful at each level.
3.) Its more than just a code review. Its about the next level of programmers picking up the code as their starting point and changing (including heavy refactoring) to make the piece of code better , perfect and world class.
4.) Each level of programmer is expected to take ownership of the code in concern. When in your level, you own it.
A streamlined approach such that the programmers down the level get a chance to learn can be implemented with difference-reports emailed after each check-in. No action is expected from the recipient developer at this stage - this just FYI; passionate developers can learn.
Upper level developers shouldn't look at the piece of work as a cleaning/reviewing process, but as a complete development process. They could treat the inputs they received as templates that are partially filled up. Think of skeletons with minimal flesh that you get - you have the flexibility to tone that piece of art based on your skill.
As you apply the same principle at each level, the code is expected to get cleaner and nearer perfection. Additionally, this makes sure that the very senior/experienced geek is not bothered with the very basic nitty gritty of things.
3 levels of programmers is a good start for any organization. Its quite easy to classify them based on the experience at any software development house.
Pair programming can be pain in some situations where the wavelength of the two developers don't match - it can get destructive for the experienced developer. With assembly line programming , the experienced developer is on his/her own during the development process.
Theoretically, the unit test cases should not be changed as we are not expected to change the functionality as such. New unit test would definitely be added as the code is polished up the levels. Having said that, there could be instances that the skeletons/contracts can get changed at upper levels.
Cost-Benefit - Each orgranization / project is on their own to perform a cost benefit analysis and tweak the number of levels as desired.
Posted at 10:35 pm