This is going to be a tough one to explain, and very much a reflection in progress.
I’m coming up to two years of working in a very enterprisey space and finally coming to terms with the cognitive dissonance that permeates my daily existence.
Internet and Enterprise cultures have some fundamental disconnects about where and how value is created. Now I’m sure that everyone went, “well yeah, duh” and I’m with you, but I didn’t realize just how much this colors people’s world view and its impact on IT.
I can explain this by illustrating how one very basic role is viewed by the parties: the developer.
On the one hand, the enterprise is built around precepts that have been inherited from the industrial age public works and construction industries: distinct hierarchies where the people at the top, i.e. the architects are the ones who, being the best educated, “know best”. Then there are a series of roles determining what the client wants, translating that into documentation (the functional specification) and then on to the people that translate that into a technical specification, who then break this down into further smaller chunks to be given to the developers - the day labor grunts at the bottom of the totem pole.
In the ‘public works’ worldview of building applications, there is no direct equivalent for the production team, the team that takes care of the code after it’s been released; a building built is a finished product and the client just lives or works in it. That’s fodder for another article.
This structure puts developers at the bottom of a chain, entirely without added value, easily outsourced to pretty much anywhere since they are the equivalent of the bricklayer. As long as you tell them where to put to the bricks and how many and with the correct type of cement, you’re executing requirements properly.
This is in stark contrast to the startup and the Internet worldviews, where the developer is more of an ‘artisan’, with different levels of expertise from the apprentice to the journeyman and finally the master. In addition there is awareness that there are many specific trades that require different skills and talents.
The master diamond cutter, for instance, is an artisan, and a subject matter expert, but would rarely come in direct contact with a client since they live worlds apart. The majority of application development is done by someone who is closer to the jeweler. The jeweler is in direct contact with the customer and knows how to ask them about their wants and desires and has the ability to translate that into a custom product that responds to their needs.
The diamond cutter is the developer we tend to keep behind closed doors and give the really tough problems involving developing new languages, codecs and other low-level complex and conceptual problems that are far removed from the banality of developing applications for enterprises and other customers.
The jeweler, on the other hand shares much with his customers. The basic needs are the similar and he might even design stuff for himself that are of interest to others. The master jeweler can talk to a customer and translate this into a finished product directly. Many of their projects come as the result of scratching a personal itch, which turns out to be shared widely.
The outsourced enterprise approach involves hiring ditch diggers, and as long as they receive sufficiently clear and precise dimensions of the ditch they are required to dig, they’ve done a good job.
To the enterprise, development is grunt work and there’s no additional value to be added by this echelon of the development corps. This is the antithesis of the artisan, who embodies the architect, engineer and artist to actually create something.
These two approaches are polar opposites in terms of determining functional spec, and so produce very different products.
While I have an intellectual understanding of the two approaches, in my heart, I adhere to the artisan vision of the developer, which makes working with people that don’t share this attitude very difficult.