I heard the term “Line-of-Sight” in reference to certain breeds of dogs, such as the Afghan.
It seems that these dogs have this instinctive urge to run towards the horizon, and if they get loose, they’ll keep running towards the horizon at full speed until their owners catch them (fat chance) or until they run out of steam.
My brother and his family have a Greyhound/Great Dane mix dog named Hillary that’s a line-of-sight dog. The problem is that she has the speed of a Greyhound and the size of a Great Dane — not a dog one takes for a walk without a great deal of trepidation.
These pooches just can’t help themselves: they see, they do.
Odd thing, though, is that I know of developers that are like line-of-sight dogs: they see, they do. The problem is that you can’t leash these folks up, at least not without breaking several laws of the land.
The Characteristics of a Line-of-Sight Developer
How do you recognize if you work with a Line-Of-Sight (LOS) developer, or are one yourself? Well, there are several warning signs to look for.
You receive an email from another team member that they have “improved” the performance of a key element in the application your team is working on, have checked in the change and is ready to move it into production. Unfortunately, none of the rest of your team knew that the developer was working on this key piece of code, much less what the change was, and how it will impact on the rest of the application. Congratulations, you’ve just identified a LOS developer.
During a team meeting, you discuss the possibility of making a change to the user interface of an application, but decide to wait and get additional information. The next thing you know, the change has been made. You track the change down to a specific developer who states “Well, I had some time so I thought I would go ahead and implement the change”. Yup, one of the classic characters of the LOS breed is the words “Well, I had some time …”.
In an environment where clients have direct access to the developers, they always approach the LOS developer with requests for changes. You see, it’s an established fact that Clients instinctively know which developer will make the requested change without question. This ability is part of the client’s built-in survival instinct.
The LOS developer can program better than anyone else — at least, that’s their own opinion. So, they’ll fix other team members code whether the code was broken or not, inefficient or not, up to specs or not. After all, it’s a tough job, but someone has to do it.
The LOS developer: they saw, they did.
Two Different LOS Breeds
There are actually two different breeds of LOS developers.
There is the “I’m inexperienced and very eager” LOS developer. I call this type of LOS developer the “WOWIC” (Watch Out World I’m Coming) developer.
The WOWIC LOS developer brings the unanticipated changes they make to you for praise and at that point, all you can do is tell them they’ve done a good job, and give them a stock option to chew on. After all, to beat them about the head with a project plan will only break their spirit — you have to approach their training more cautiously than that.
The second type of LOS developer is harder to work with but thankfully less common than the WOWIC LOS developer. The chief signs of this type of developer is their arrogance, so I call this breed the AAH (Arrogant A**H***) LOS Developer.
You can easily recognize the AAH LOS Developer — one of their chief hobbies is to go through their teammates’ code and change it to what they believe is better code. If the teammate disagrees with the change, the AAH LOS developer looks at them as if they were an amoeba that just started to sing the “Star-Spangled Banner”. No one disagrees with The Programmer.
Dangers of LOS
Anyone who has worked on a larger application knows how dangerous a LOS developer can be. What may seem to be a simple change in the code for one application module can have disastrous effects on the application as a whole. If the change is in shared code, the developer has a responsibility to inform others before making the change. Better yet, the change should be incorporated into a staged development rollout, to ensure appropriate testing.
Another danger of the LOS developer is to the morale of the team. If you have a developer, particularly an AAH LOS Developer, grabbing other people’s code and changing it without legitimate cause you’re going to have dissension in the group. This type of behavior is discourteous. This type of behavior is costly to the development effort. Really, this type of behavior is just plain rude.
To make changes daily or even weekly and just plunk the code in without a plan only disrupts the work of other developers. I’ve found that any language that supports class inheritance, such as Java or C++ is particularly susceptible to this type of “ad hoc” code changing.
Is there a cure for LOS?
As stated there are two breeds of LOS developers, so there are two cures.
Having a well-established change control system and good software development procedures in place are about all you need to train the WOWIC LOS developer. They’re eager to please so showing them that good programming practices and teamwork support are just as valuable as lines of code will get the point across, quickly.
How about the AAH LOS Developer? Well, sometimes all you have to do is tell the AAH LOS Developer that they’ve tromped all over the team’s code and to please not do so in the future. If they’re more arrogant than A**H*** this could work.
However, the best approach with the AAH LOS Developer is to again set procedures in practice that curb the more I, PROGRAMMER urges of the AAH LOS Developer. In other words, track what the person is working on, and keep them busy enough with their own assignments to leave other people’s work alone.
Oh, did I mention that you need to have good programming practices, change control, and well understand project plans in place? I did? Just wanted to make sure.