Developer as Typist
by
While not conceptually the best metaphor for developers, the typing pool is perhaps the most common view of developers. Before the advent of the word processor it was common to have pool of people who did nothing but type stuff up. Businesspeople wrote long hand and needed letters and memos typed and spell checked. That’s exactly what the typing pool did. The piece was dropped in the in-box of a typist. Almost any typist was fine as long as they typed X words per minute with an error rate of Y. It really didn’t matter as long as the pool continued to churn out reasonably good quality typed documents. Sometimes called a secretarial pool, it was generally cheaper than giving everyone their own secretary just to type up a few documents.
Fast forward a few decades and we see businesses treating developers in much the same way. Developers are in the IT department and are assigned projects based on certain technology standards. Because of the standardized tools and techniques, almost any developer should be able to perform the work. The goal is to produce a functioning application at a certain cost. In part this model allows the centralization of developer resources out of particular departments and into a central IT organization. As a bonus, this model frees you to look for the best price on developer resources locally, nationally or globally.
How can this model possibly be broken? If we’re dealing with very standardized pieces of work, then we should be able to dole them out to any competent individual and expect adequate performance in reasonable time. It should be apparent that there is an underlying assumption that the work asked for is ‘standard.’ Generally, when you need a custom application, you’re asking for something non-standard. If the application were truly standard it would be written by a developer (or company) that took some iteration of the solution and packaged it into an open-source or COTS product. If you need something ‘standard,’ and you’re having it custom built, you’re re-inventing the wheel.
We’re really talking about non-standard items. The problem to be solved might be something like a time-sheet application, but because of some constraint (like the format of the data to be saved, or the sheer scale of the problem) it winds up as a custom piece of work. There are usually dozens of ways to solve similar IT problems that are almost all equally valid. Sometimes the most straightforward and simple are the best. Sometimes even apparently trivial problems require more detailed thought. A developer’s experience, subject area knowledge, and natural talent allow the developer to determine what exactly needs to be done.
As a real example, imagine an on-line forms application. Solution 1 might be to create a data table to store each type of form because they all have different fields and the available tools map 1 object to 1 table. Solution 2 might be to engineer a generic storage mechanism and a meta-data based approach to managing forms and related workflows. Using the tools available many of the client’s developers felt that solution 1 was the less efficient but unavoidable solution. It would result in dozens (if not over 100) database tables. Solution 2 was pursued by asking for a waiver from the official developer tools and server stack. The developer used their experience and knowledge to make their case to use non-standard tools to build a more efficient solution.
The typing pool approach was happy with solution 1 because all pieces stayed the same. The same object-relational mapper. The same database design approach. The same storage mechanism. The result, however, would have been an almost unworkable solution. Solution 2 required thinking outside of the box. That’s what you should be looking for in developers. You should be looking for creative, thoughtful people that have experience and knowledge to craft solutions.
It’s interesting I settled on the word ‘craft’ to describe what a developer does to build a solution. Like a table, chair, or home, a solution can be technically ‘correct’ and working but poorly crafted. A good developer, in addition to being creative, is also like a good craftsman. The work should be able to stand up over time. It should be modifiable and maintainable, even years after its initial launch. As a concrete example, I once worked with a developer that produced working code but it was horrendous code that had to be rewritten. It was enough for him that it worked.
The typing pool approach to managing developers results output that works as long as no one has to meddle with the code. Even with all the modern tools and methodologies at hand, nothing guarantees that the resulting product is well crafted. Unlike set-piece workers (for example assembly line workers or typists) developers aren’t solving the same problem over and over again. It’s hard to judge the quality of their work without actually looking into the code. A typist or set-piece worker usually has some readily identifiable measure of quality – like number of errors, tolerance between fitted parts, etc. Without actually being able to evaluate the code, most consumers of IT services just have to trust it’s good quality work. They can’t compare it to the previous program, which might be in a totally different subject area and a completely different level of difficulty. It’s like having a typing pool that types up your letter in a language you don’t understand and you just have to assume it’s done well.
The only way around this is to look at developers individually. It may seem hard in companies with dozens or hundreds of developers, but managers should really take the time to develop an understanding of the developers as individuals. It’s not that managers de-humanize developers. It’s that it’s easier for managers treat the developers as being fungible resources instead of looking at individual skill level, experience, and aptitude. This is especially true when the manager is not a technical person. This view is reinforced by a market for IT services that sells “resources” with a standard litany of skills, listed in “representative resumes.” The implication, of course, is that there is a pool of clones from which they will pull your ‘resources.’
So, every developer is a wonderful snowflake, unique and special in every way. Why have standard this or that? The reason we have standards, however, is not to homogenize developers, but to ensure they can communicate with each other in a standard manner. It ensures that we all agree on a common set of tools that have common interfaces, so we don’t have to start from scratch on every project. I have yet to see developing custom software, an inherently creative endeavor, reduced to something that was done well in the typing pool model (which works against creativity). The best software. The game changing software. The software that can produce an competitive advantage is crafted by creative people close to the subject matter.
Previously: What is Cloud? by