Code is Play Dough
I started my career as a developer with a technology consulting company called KPMG. There I learned the phases of the software development process - Requirements, Development, Testing, Operation. And each of these phases required domain specialists who would hand their work off to the next set of specialists when the next phase began. This model was inspired by Henry Ford, who taught us that dividing work into repeatable steps could reliably and efficiently produce Model T’s.
The typical project went as follows: the business analysts wrote specifications and produced mockups. They debated scope. They drew UI concepts on whiteboards. They spent months perfecting the specification for our new system. They called it the Rosetta Stone - the source of truth.
With the Requirements phase done, the developers ramped up. On day 1 of the “Development” phase, the Rosetta Stone was plopped on each of their desks with the expectation that the specifications lying within would be quickly converted into working software. And of course, because all of these requirements had been captured on paper, the analysts who created them were free to join the Requirements phase of the next project with the next client.
Now, developers can’t convert requirements into working, cohesive code. We need architecture. Enter the “Enterprise Architect” - the elite of the elite. These seasoned guys were former developers turned Visio-jockeys, and they would cleverly convert the Rosetta Stone into arrows and boxes representing architectural components. The Enterprise Architects had a keen understanding that we were building the groundwork for a system that would, one day, be the foundation upon which every new system would be built. And because of this inevitability, we needed services. Lots and lots of reusable, generalized services.
Debates ensued about which services to build. What data would be passed between them? Which services would be allowed to talk to databases? Would they use SOAP?
Once these important issues had been agreed upon, it would be time for developers to dive in. Using the Rosetta Stone they had previously been given and newly pressed architecture documents as references, the first lines of code were written.
Usually by this point the project was six months old.
I’ve often questioned the value that BAs and Architects provide here, especially given the time required for them to produce anything interesting. The argument most people make in support of them and their work is that it’s much cheaper to edit a document than it is refactor code. As a developer, this line of thinking has always felt off. But I couldn’t quantify it until I read a comment by Jason Calcanis a couple of years ago. Jason was trying to figure out how Facebook had ascended to its position of dominance in comparison to other technology companies. His conclusion was that
Developer-driven startups always produce product faster. This stands to reason: our nontechnical people are having discussions and debates while Zuckerberg is coding his next feature. This is why no one has been able to keep up with Facebook! While MySpacers debated how to iterate on their product, Facebook simply tried stuff. Yahoo has been in strategy, reorg and cost-cutting meetings for the past five years, and is run by an amazing operational CEO, Carol Bartz. But what was the last good product Yahoo released? AOL has been branding itself wonderfully to Madison Avenue, hosting really awesome parties and wooing Wall Street on their roadshow with dashing, advertising-driven CEO Tim Armstrong. But what was the last good product AOL released? Yahoo and AOL have had the raw materials to compete with Facebook since its inception, but neither has been able to release a single kick-ass competing product. Let me say that again: AOL and Yahoo have not released a single, kick-ass product in a decade.
Developers are some of the most creative people I’ve ever met. After my consulting career I moved on to manage 12 development teams comprising 70 developers. Needless to say I’ve met a lot of developers.
I firmly believe that code is to a developer what paint is to an artist. It’s a medium used to create. And it’s a highly malleable medium at that. Just as it’s easy to resculpt an animal made of play dough, it’s easy to manipulate a system made of code. And if more non-technical people understood that, they might structure their businesses and their processes differently. They might start developing and prototyping at the beginning of a project. In so doing, they might realize speed and efficiencies they never thought were possible.
This is our mindset at popexpert. We built a working version of our product in three months. We have no business analysts. We have no product managers. We have no architects. We’ve shaped and re-shaped our product continuously in response to hypotheses and feedback. And we like playing with play dough.
