Deep thoughts: Evolve your narrative by coding and writing
Published: 1 Feb 2015I will like to invite you to, for a moment, empty your mind of all the knowledge and techniques that you’d acquired on software development.
I will also request that you cast aside all the product management know-how you’d accumulated for a while. Leave agile methods, feature lists and marketing what-nots at the door. Not that those aren’t relevant, it is important and very related, but just let it go for a while.Now, imagine you start with a single idea of something to express. Not something trivial, but a ball-park idea. To a writer, it can be an essay, or even a book. To a developer-entrepreneur-product person (sorry, I am not aware of a hip English word for that yet), it can be a software product. Something like these:
“A novel based on the dystopian fall of theme parks in the future, and its eventual rise”
“A tool that allows you to make financial sense of all your cloud-based resources”
Then, you start with this broad single idea, and start breaking it down to chapters and features. Within each chapter, you’ll fill in a few points. As with features, tasks. Then you start coding and writing out those points and tasks. What happens then?
As you go about focusing on certain points or tasks, your brain sets the context for you. You immerse yourself in the domain. You become one with the domain. You’re ready to shape and codify certain early thoughts. Then it strikes you. That moment when you actually have to think deeply. Deep thoughts bring about a lot of questions:
"What if the big guy manning the ride gave all residents in the trailer park free rides?”
“What happens if Sarah decides to stay for another week?"
"What if the user shuts down the server in the first week and starts it again on the fourth week?"
"What happens when the amount of rows hits the limit of database?"
“How will the data bandwidth charges be impacted if we keep moving servers between clouds?"
This doesn’t happen on all points or tasks, but it happens to many or most because somehow all parts makes the whole. But what does this mean? So what if I have such deep thoughts? Isn’t it normal and a rite of passage in getting a product to maturity?
Yes, definitely. But think about the last time you were given the space to explore the chapter or task within the domain in such depth, in a commercial, project-managed endeavour. There may be some good experiences for the lucky ones, but more often than not, such deep thoughts happen more often on individual projects, with those without a schedule nor an imminent business stake.
What are we missing here though? Are these “deep thoughts” all that important?
Besides the obvious benefits for overall software quality, these thoughts in my opinion are a vital source of product differentiation and creativity. Every thought is an impetus for a novel approach, a new opportunity to differentiate, set the path for the sequel or even pivot. It is also the point where product, strategy, timeline, marketing and technical decisions meet within a micro-context of the current thought. Casting such deep thoughts away to “focus” on completing the task at hand will result in a bland, indifferent outcome. Something with no soul. The embrace of such deep thoughts along with the courage to follow through, either by investing more into it or transferring its livelihood to the team will result in better software or writing. One that is unique and soulful.
Thing is, the people with the most opportunity to engage in such thoughts are the developers and writers, as they execute the implementation of the points or tasks at hand. I am not saying that the opportunity for deep thought on a specific point or task is totally closed off to other roles, but I don’t think anyone can deny the thoughtfulness that needs to go into the work of coding or writing the actual thing.
Corollary to that, instead of handing over the coding or writing work to developers and writers, I will recommend that everyone involved in the making of a creative product get in on the act. Instead of investing too much time and resources producing the specification, which will never be sufficiently detailed (unless it is space shuttle software or something like that), or guarding the timeline, which is unlikely to be sufficiently precise; product team members can better serve a project by actually picking up a task or point or two and actually start implementing it. This may sound a little extreme, but isn’t such a far-fetched idea if you give it a chance.
A creative or software organisation needs to understand that development is not like an assembly line, or even worse, something that can be outsourced. The demographics of a creative software development team is rapidly changing as well. Some modern schools are already teaching programming. It can be as ubiquitous as biology or economics for example. The best software companies has leaders that continues to dedicate some time to code (take Lewis Cerne, CEO and Founder of New Relic for example). Programming languges also continues to become easier to pick up.
I suppose a more pragmatic, interim alternative to having everyone being more involved in code for the purposes of such opportunities of thoughts will be to create a closer relationship structure between developers and product leaders, or to give developers more voice in product leadership. Additionally, the product development pipeline can be shifted from one that is sequential to one that is more evolutionary. Agile methods are a good path towards such possibilities, though organisations should couple such adoption to be flexible not just towards technical evolution but product and business evolution as well. This requires the right education and reward structure that will involve more interaction among members at every stage of organisational and product growth.
In any case, it is time for us to shift from a perception of coding (and writing) purely as an act of implementing ideas, but as an avenue to evolve the narrative of our idea, product and purpose.
Find me here: http://twitter.com/vitoc
