Developers, Developers, Developers

To quote a fairly recent tirade executed by one Steve Ballmer of the Microsoft Corporation ‘DEVELOPERS, DEVELOPERS, DEVELOPERS!”. It’s all about the developers. Here at TAI we have a number of folks who are classified as developers amongst other designations. This is because their primary function in their jobs is to craft working bits of program out of literally thin air. This makes them all a member of a subclass of developers known as software developers, as opposed to other kinds of developers like Proposal, Hardware, Land, etc. etc.

On the outside looking in software developers, like all developers appear to have a very similar path to tread in their daily chores. While the tools used to do so may differ from vocation to vocation the process appears to be the same. You look at a tasks defined outcome. You look at a tool set to act on raw materials, each one in application to the set inches the end result, closer and closer to the desired outcome. Like a sculptor chiseling off hunks of rock to reveal the form desired within. Or a landscaper carving out part of the hillside to reveal that terraced build up that will hold the parking lot, finally electronic designer adding in that final collection of silicon chips to create the water heaters sensor logic. The tools employed were all very different but the processes were all the same.

Software development is different though the differences however, often defy explanation. I however believe those differences can quantified by examining the tools used in that profession vs. those used in other development professions. Software development tools I believe fall into two broad categories.

Physical/Real/Tangible

• Development environments
• Programming Languages
• Database manipulation tools
• Report Generators
• Pre-build software components
• Code generators

Mental/Idea Based/Intangible

• Patterns
• Algorithm Applications
• Domain understanding
• Subject Matter Awareness

With physical/real/tangible class of tools it is easy to define the circumstances of the tools use and the how to use said tool in solving a particular problem. Indeed everybody who has taken any courses on software development will no doubt remember their introduction to the domain as being largely “This is how this tool is used to do this task” oriented. It breaks down into a problem/solution checklist style of software development that is well suited to other disciplines but ultimately fails in complex software development, for one simple reason.

Problems are rarely the same in all respects from one delivered solution to the next. The differences although small in magnitude often invalidate an application of one solution to another problem space. Even if a developer knows going in that there are data changes that invalidate some aspect of a previously delivered solution. Just knowing this does not necessarily mean that said developer can effectively morph solution A to problem B’s space. Having wonderful tools and the perfect programming language and a wiz bang development/reporting environment may help produce miracles but not unless they are in the hands of a person who has copious amounts of the second category of a developer’s tool set.

The mental/idea based/intangible aspects of software development are, I believe, most important to a developer being passable vs. stellar in what they do. While an individual trained in many of the colleges and universities available today may certainly have a firm grasp on the tangible domain of software development. A lack of grasp for the intangible however will make for a marginal developer at best. The reason primarily is that problems rarely fit into the cookie cutter realm that university exposes a person to. Its never cut and dry. Specification of the attributes of a problem domain are often obscured and often enough non existent. Experience often enough will fill in these voids in a developers tool set, if that developer is capable of learning from their mistakes and is able to recognize a mistake in the making. The issue here is can they recognize a mistake in the making.

Often enough in any large scale development effort there are a set of folks who are the stellar types. These folks examine problems and can digest them down to simple well defined steps that they then hand off to a different developer to actually implement. The person who actually implements the bit does not ever get a chance to observe their mistakes because they don’t get an opportunity to make any. I contend that if you take on a person who has spent 10 years in such an environment at such a level you might as well have taken a person fresh out of university because they are for all intents and purposes the same level of developer.

So how does one developer at a junior grade get to have the domain experience and subject matter awareness that making mistakes affords them, if they have a job where they are spoon fed the work predigested and ready for consumption?. If they are not allowed to make mistakes and learn from them, and are shielded from the domain problem and subject matter then these individuals have to be willing to learn outside of their professional careers. I have observed many said individuals over the years and some commonalities stick out like sore thumbs. They are all geeks. (In a good way). They all come with varied written materials that are seemingly off direct topic. They always have their nose in a book or trade rag when it’s not in their flat screens. Their hobbies are often enough technically oriented as well. Some might equate this sort of behavior with being a pocket protector, taped eyeglasses, to short blank pants white socks, black shoes wearing, socially inept individual portrayed by the media. Stereotypes being ugly, in this and in all cases. Fact is a person who likes what it is that they do professionally often has their personal interests aligned with their professional occupations and I would argue that such a person will naturally become better professionally for it.

Another characteristic that good software developers exhibit is that creative spark. When a sculptor looks at a block of wood, their creative mind allows them to see the end result almost as clear as if it were already created. You can be taught all the technique in the world, unless you have some ideas on what to do with those techniques in a non scripted way I don’t believe you will ever be creative enough to graduate from fair to truly great. No book out there that I have ever read instills creativity. Now it can be fostered and nourished but it has to be there already to do so.

Startling revelations? Hell no. In fact my book shelf has many such observations penned by others previously in more or less the same frame. I have read these prior works in the past, and often enough re-read these items just as a refresher. One thing about all this that I have not read in the past is the examination of how a team dynamic contributes to a development effort vs. the loose cannon, lone wolf style of developer.

To be sure some of TAI’s more useful internally developed items were largely developed out of thin air by a single individual. Some of our Code generation tools and our internal software components that we leverage day in and day out were developed by myself over a period of time. But I contend that though these development items have proven very successful, and were largely developed by a single individual. They benefited from the team dynamic and would not have been nearly as widely employed had that dynamic not been present during their inception. Fact is that no meaningful development occurs in a vacuum.

Case in point, when I started writing our own Grid control some years ago I had a couple of key features I needed (Like I needed to be able to sense user interaction at the cell level). As this was implemented I would have been content to use my new creation as is, but others here sought to have the item do more. Their feedback contributed to new versions that added new features sometimes resulting in multiple version a day. Nothing new really just a team dynamic at work in a development effort. That team however existed in a closely confined area. We were not separated by some distance with only our internet connections between us. We were all in the same room and could freely talk with each other when a problem arouse. There is a lot of development being done across widely separate geographies today, so its not an absolute must that everybody on a team be connected at the hip but it does make it a hell of a lot easier to hash out problems or explain concerns and issues. The orchestration of geographically separate development teams or single developers takes some amount of energy away from the inertia of the project. As in physics, there is no perpetual motion machine, there is no such a thing as a free lunch. As important as communications between developers is, I feel that communications between novice/new developers is even more important. Nothing really new here either just an observation on my part that if a person is experiencing something for the first time, they can benefit from others looking at the new thing with them. Not easy to do alone in a room separated from anyone else in that clique.

More important however is mistake learning. I have been handed things that were done by someone else that did not work as intended. I will admit to doing that someone else a disservice by just fixing the issue myself rather than pushing it back as unacceptable with reasons as to why and suggestions of correction. Under the tight time frames of today in the 70+ hour of the week it’s just easier to fix it yourself. That however I have come to realize perpetuates the problem and in the end solves nothing. The original author does not know the issue they created and its implications. I can expect more of the same next time around.

So at the risk of stating the obvious (I am after all a thick headed, knuckle dragging, ape, just ask my wife sometimes)

When it comes to developer teams

• Spoon feeding tasks to novice developers really teaches them nothing.
• Having developers work in isolation reduces efficiencies and robs a development of inertia.
• New developers are better off being exposed to their own mistakes and being tasked with correction of those mistakes themselves
• Software development is part hard science part art and the art part plays a bigger role than one would imagine.
• Creativity cannot be taught you either have it or you don’t.
• Lots of experience does not necessarily a great developer make.
• Communication amongst team members is I feel the single most important aspect of fair vs. great teams
• Wonderful tool and tool sets only allow you to get so far. (though in the right hands they can prove miraculous)