IT Obstacles: Arny the Super Programmer
There are many Software Development Lifecycles in the market, and most of them are very successful when paired with the right type of project.
From the early standard waterfall lifecycles which progress through requirements, design, programming and user acceptance testing to the RAD and agile cycles which are more iterative and allow far more interaction with the programmers and designers, there are still two common threads: 1) someone has to have a vision of what the product will look like, and those translate into some type of requirements and 2) someone has got to write the code.
Now this may seem simple, and in some cases it is.
If you want a simple database with 10 fields and a small web front end, that can be pretty simple.
If, however, you want a complex application that utilizes a lot of different types of rules and presents data in different ways, it is not so simple.
Occasionally I have run into programmers that are so far ahead of the curve that they seem to read minds, let's call out super programmer Arny.
Arny seems to see a vision and have multiple solutions instantly for resolving the vision and moving it forward.
In many cases Arny may well be the best thing since the original CPU as his solutions work quickly and effectively based on previous experience and code.
Arny may quickly be adopted by management as a solver of problems when he is solving issues and more often than not, those persons in management do not understand much about Arny and his solutions, just that he has delivered at least once.
Common issues with programmers like Arny start with communication.
Arny may not be used to dealing with written requirements and instead be focused only on the solution, communication can quickly suffer as people do not have the information necessary to see requirements have been addressed.
With quality or validation groups this becomes paramount.
Arny's relationships may be difficult to manage as he may have the "ear" of a manager or executive, but his solution may not be the best solution, and it may not fit with global enterprise architecture.
Arny's team mates may also suffer potential issues as they are ignored in situations where they may well have solution solutions, but do not fit with Arny's program.
Finally Arny may be so far ahead of the vision that his solution just cannot scale to the level necessary or does not have the forethought to consider secondary requirements.
In one case I saw a super programmer like Arny write a piece of complex code in only a few days.
HE utilized code libraries he had built and created a complex data collection and reporting system over a weekend.
Instantly he became the focus of attention, however as we reviewed the code it was readily apparent he did not utilize some good coding practices and had multiple procedures doing the same thing, making his code difficult to debug, and as hard to modify.
For some time he had great focus, but eventually lost momentum as changes become more and more difficult causing the program to be completely rewritten.
How do we handle these situations? First: Before utilizing a programmer a group should have a defined Software Development Methodology and a reasonable coding standard.
Next: Before any project can be begun, written requirements need to be on hand.
Every SDM or SDLC requires some type of requirements to start the project.
Next: Foundations for success must defined.
An executive with an idea is not a good idea until he or she says this is how we will define success.
Finally: a good technical project manager and team must supplement and work with Arny to make things a reality.
Tasks must be distributed and the good technical project manager can lead Arny in the right direction and keep the free flow of "what if" solutions in check so that expectations can be met, or better yet, exceeded.
From the early standard waterfall lifecycles which progress through requirements, design, programming and user acceptance testing to the RAD and agile cycles which are more iterative and allow far more interaction with the programmers and designers, there are still two common threads: 1) someone has to have a vision of what the product will look like, and those translate into some type of requirements and 2) someone has got to write the code.
Now this may seem simple, and in some cases it is.
If you want a simple database with 10 fields and a small web front end, that can be pretty simple.
If, however, you want a complex application that utilizes a lot of different types of rules and presents data in different ways, it is not so simple.
Occasionally I have run into programmers that are so far ahead of the curve that they seem to read minds, let's call out super programmer Arny.
Arny seems to see a vision and have multiple solutions instantly for resolving the vision and moving it forward.
In many cases Arny may well be the best thing since the original CPU as his solutions work quickly and effectively based on previous experience and code.
Arny may quickly be adopted by management as a solver of problems when he is solving issues and more often than not, those persons in management do not understand much about Arny and his solutions, just that he has delivered at least once.
Common issues with programmers like Arny start with communication.
Arny may not be used to dealing with written requirements and instead be focused only on the solution, communication can quickly suffer as people do not have the information necessary to see requirements have been addressed.
With quality or validation groups this becomes paramount.
Arny's relationships may be difficult to manage as he may have the "ear" of a manager or executive, but his solution may not be the best solution, and it may not fit with global enterprise architecture.
Arny's team mates may also suffer potential issues as they are ignored in situations where they may well have solution solutions, but do not fit with Arny's program.
Finally Arny may be so far ahead of the vision that his solution just cannot scale to the level necessary or does not have the forethought to consider secondary requirements.
In one case I saw a super programmer like Arny write a piece of complex code in only a few days.
HE utilized code libraries he had built and created a complex data collection and reporting system over a weekend.
Instantly he became the focus of attention, however as we reviewed the code it was readily apparent he did not utilize some good coding practices and had multiple procedures doing the same thing, making his code difficult to debug, and as hard to modify.
For some time he had great focus, but eventually lost momentum as changes become more and more difficult causing the program to be completely rewritten.
How do we handle these situations? First: Before utilizing a programmer a group should have a defined Software Development Methodology and a reasonable coding standard.
Next: Before any project can be begun, written requirements need to be on hand.
Every SDM or SDLC requires some type of requirements to start the project.
Next: Foundations for success must defined.
An executive with an idea is not a good idea until he or she says this is how we will define success.
Finally: a good technical project manager and team must supplement and work with Arny to make things a reality.
Tasks must be distributed and the good technical project manager can lead Arny in the right direction and keep the free flow of "what if" solutions in check so that expectations can be met, or better yet, exceeded.
Source...