Developer-Driven Is Not A Panacea

Idea of developer-driven or developer-centric organizations is being actively discuss lately thanks to the likes of Facebook. Some people, mostly developers, love it for its freedom and lack of heavy processes. I love it too – to a point. I believe in its usefulness while a product is being conceived, while it is in the prototype or even in a rapid growth stage, while creators of the product have neither rich user data nor significant market penetration. In these situations, product team does not have any data to guide their development direction, and therefore tries to probe with multiple features.  However, there are obvious downfalls even at this stage:

  • Developing cool new features before core functionality is in place is meaningless at best and distracting you from your mission at worst
  • Developers left to their own devices tend to over-engineer most of the features and create flexible frameworks for everything, even trivial things
  • Most developers suffer from NIH syndrome, which leads to everything being written at least twice if not more

Let’s assume now that the product is becoming successful. It is growing in size, gaining more and more fans and/or more and more revenue. At this stage blindly following Developer-Driven process can get you into even more trouble.

Business:

  • New features developers chose to implement may not be helping your product
  • New features developers chose to implement may not be what your users want most or want at all
  • New features developers chose to implement may be cannibalizing or hurting other important revenue-generating features
  • New features your developers chose to implement may not be the most profitable

Technical:

  • Duplicated code grows all over the place and when new features are being introduced, raging debates start about what to use and what to retire and why. There is no consensus, so different factions continue to use and improve their code of choice ignoring others.
  • Set of home-grown tools emerges that mostly work, but nobody is completely happy with them, so from time to time somebody creates new tools that do almost the same thing but “better”. Maintenance costs continue to grow…
  • Documentation becomes so far outdated that knowledge about overall system architecture is priceless and can only be found with people who have been on the team since its inception.
  • Build takes forever because of the amount of code. Configuration is mind-boggling because it is hard to configure dozens of “data-driven” frameworks to actually do what users want.

I could continue this list for a while, you know…

So what’s the solution? In my mind, it is very simple – provide a system of lightweight checks and balances that will keep the good and eliminate the bad:

  1. Get a good PM on the team. Give them broad authority to influence and little authority to dictate. Make them work together with Dev and Test teams. Good PMs hate process just as much as Developers, and they will provide an excellent balance against cowboy development and over-engineering problems. More importantly, this move will compliment technology focus of Dev-driven product with razor-sharp customer focus.
  2. Get architects to actually do their job. Architects who design how features should work should also be capable enough to quickly code up reusable and complicated components and provide actionable feedback and oversight to other team members. However, architects who sit in an ivory tower are just as bad for the product as no architecture at all. Therefore, getting seasoned developers to become architects (i.e. experts) on the product is a better way to go, I think.
  3. Use experimentation in addition to (or instead of) traditional marketing research. Once a product get beyond initial rollout stages and starts gaining steam, the only way to grow effectively is to use data, quickly try out new features, measure, and if ideas fail (most of them do, by the way) – fail early and get out.
  4. Watch over the buildavoid having dedicated build team, keep number of branches to a minimum, make developers responsible for integrating code. This will serve as a forcing function to have a reasonable component architecture and inject enough engineering discipline.
  5. Do not subscribe to “good developers write bug free code” myth, invest in test infrastructure, measure test coverage. Once again, placing test responsibility with Developers can be used as a forcing function to inject stability and reason into your code base.

In short, maintain user-centric focus, keep it simple as much as possible, use real data, trust but verify.

Advertisements

One comment

  1. Angela

    Well said. Ever dev-driven organization I’ve seen fell into at least one of the traps you mentioned above. So long as process is agile, there’s no reason having additional disciplines involved should slow anything down.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s