Three Streams of Software Development

Posted on

We software developers have long fought against technical debt in our codebases in a variety of ways. Ultimately it seems we settled on doing a little bit at a time in an ongoing effort to slowly “pay off” what we have built up over months and on some projects, perhaps even years. Maybe you factor this into each iteration, with dedicated tasks that get their own story points score, or maybe the developers are instructed to enter a phase of “leaving everything better than when you found it”, relying on bugfixes and feature improvements to instigate updating the code to the latest agreed-on practices. Either way, that battle is won in a lot of environments (I’m an optimist), and that means you have two streams of development in your team:

1) Business-value development: This is stipulated, specified and analysed functional work that is prioritized by the business and offers direct value to your customers. This traverses your entire value stream: Analysis –> Development –> Testing > Deployed to customer

2) Technical-value development: This is prioritized by the technical team and has indirect value to the customers by increasing the speed/quality of your development. It also effectively skips the business analysis part: Development –> Testing (for regressions) –> Deployed


But I think we lack a third stream. In the enterprise, where roles and functions are often clearly delineated, there is a certain type of development that is “lost” as it is not explicitly owned by either the business or technical teams. In my experience this type of development often centres around usability improvements and innovative feature ideas. The business won’t request work to make a particular page more “usable”, and often they don’t have the skills or know-how to point to more intricate problems that would result in a better user experience. Even if they do, it’s often difficult to justify the business value against other issues in the backlog of much more tangible benefit. From the technical side, developers are discouraged to suggest improvements since they’ll have to convince the business to allow them time to develop a new feature or improve an existing one. Then again, the business would rather spend that time on what they perceive to be more urgent issues. Over the long term, without a product owner who understands and is passionate about the benefits of good web usability, the power of user feedback, integration with social media platforms, et al the result is a product that is not well-rounded and lacking in a certain kind of polish.

That changed where I work a couple of years ago, with the introduction of 10% Innovation Time (similar to the oft-referenced Google 20% time, just half ;-). Innovation Time gives developers an opportunity to experiment on whatever they wish as long as the intent is to “benefit the company” in some way. So far this has usually taken shape in the form of separate applications either automating back-office admin. But what about improving the existing product? Of course, a developer can’t just hack together a feature and commit it, since there are some necessary checks that feature developers usually go through – Does it make sense to have this new feature in? Is the value worth the development time/effort? etc. Essentially these questions are avoided by two things: 1) The developer can hack on whatever he wants in his own Innovation Time (largely escaping “Is this worth it?” question), and secondly, all innovation output that affects the product in a way an end-user can experience a different, should be given the go-ahead by the Product Owner. So in essence, this is a third stream of development that would over time, enable the developers with good ideas to get them into the product.

As far as User Experience is concerned, software teams these days are making more use of specialists in this area. For a team that currently produces a product with a lower-than-par user experience, I think it is just a matter of hiring a specialist (UX consultant, front-end engineer, whatever) and fitting him/her in at the right place in the value stream, ie. somewhere around development/design of the front-end of any particular feature. This specialism should not be an afterthought like testing/QA was in the software industry of several years ago. The UX person should be in on the conversation before any code is even written.

“Any fool can make things bigger, more complex, and more violent. It takes a touch of genius-and a lot of courage-to move in the opposite direction”

– Albert Einstein