Design, build and invent your way to a startup, Part 1: The Invention Process

Design, build and invent your way to a startup
Part 1: The Invention Process

The process of designing and building software is an invention process.

Like inventors, software designers are striving to solve a problem of consequence in the world. Whether driven by personal passion or economic savvy, software designers may be entrepreneurs, digital designers, or developers. The best entrepreneurial teams include members who can wear one or more of these hats. 

Along the way a disciplined software designer researches and refines the problem. We often call this process market research, but that is understating what really needs to happen. The software designer needs to know not only "what the client will buy", but what will drive them to come back to partake in the software again and again. And this is not a question that can be deeply answered in a single focus group. Yes, a focus group is a good starting point, but the problem definition must combine an intimate knowledge of human preferences, human behavior, economic and technical challenges.  For example, as fun as it would be to watch on youtube, it isn't enough to invent a one-time toaster that fully combusts after the first piece of toast. We need to design a reusable device that serves up tasty toast (or useful software) for many years to come.

Intrepid software designers often find that they must pivot their solution to solve a variation of the initial problem. Many articles will talk about the economic drivers behind entrepreneurial pivots, however technical challenges are often under-reported catalysts as well. In our example above, the team would have pivoted when they realized that to build a long lasting business, a toaster needs to be a reusable and flame proof device.  And too, in sophisticated software we have other considerations.  For example, while a 3-D rendering of a building may be quite beautiful, under what circumstances is creating 3-D renderings reproducible at scale? This is why software engineers are valuable contributors from the beginning of the invention process.

When developers engage with a presumably completed software design, much of the invention process still remains to be solved.  It is not enough to design a big picture solution to the problem. The technical hard parts are often not discovered until developers start working through how the software will be built. In older approaches, designs were "thrown over the wall" and developers would quickly discover multiple technically foreseeable dilemmas within the design. This then led to many extra weeks or months of development, and projects would run out of scope and over budget.  In our modern, agile approach to software design, technical insights are sought early, and developers and their non-technical colleagues have the opportunity to revisit design decisions that affect the economic and technical feasibility of a solution. 

Thus the software design challenge is not solved until the developers have had a chance to imagine (and preferably proof test) the hard parts of the technological response to the problem.  Some solutions may be mostly known, formulaic or combinations of known solutions. But other solutions require a unique combination of components, algorithms and techniques.  Thus the software design process cannot be complete without making room for software engineers to respond to the problem, early and often.  

What does that technical response look like? Responding to a design, engineers will sound conservative, explaining trip-hazards and dangers within the system.  When engaged creatively in the problem solving process, however, developers may also have new ideas (sometimes better ideas) on how to solve a particular problem. A developers insights can be the ten percent needed that changes a mediocre application into an outstanding solution. These are the ideas to listen for, while making sure that the very real warnings and dangers are also addressed.

In practice, the developers response to a design challenge is an architectural design composed of software constructs, systems, models and components.  But thinking of these as fixed solutions creates another challenge.  The world isn't a static place, and answers in software are rarely everlasting.  The most important thing to remember as we build software is to give ourselves strategic space to recognize and pivot engineering solutions based on market changes, new opportunities, and sometimes outright design failures. Being willing to throw out, refactor or change code is often the shortest path to successful systems.

Being willing to do the same rethinking with designs, is also probably the shortest path to entrepreneurial success. Sometimes, the solution designed just after the one that lies crumpled on the floor, turns out to be the best solution by far.  Meanwhile, engineering can play a huge and useful role, such as solving 
market force challenges by systematically testing design ideas with methodologies such as A/B Testing. These methodologies enable us to get ahead of needed design changes and provides insurance that the product is designed without the undue influence of the inherent biases of the products creators.  The web has enabled us to deliver software on a weekly or even continuous basis. Seeing software as a product that is ever-evolving is key to a successful enterprise. Test early and often.

Historically, well-planned and theoretically well-thought out projects would go astray. Software engineering was riddled with the baggage of missed deadlines. It was assumed that projects would be over-budget, out-of-time, and bloated beyond belief.  Out of this grief ridden world of failed projects, a little idea, that of "extreme" programming and later "Agile" development began to take root.  In essence, developers and development leaders began to embrace the "pivot." At its essence the idea of "Agile", was that software development was an invention process.

In those days, and sometimes now, in the most constrained environments, developers might have been told to "stay focussed," "just implement it,"and "do what you are told." Today we understand that developers hold the key to understanding not just the "what must be built" but also "the how" and sometimes "why something might be better if built a different way."  Developers are intimate with the algorithms, with the core issues and often even with the humanity of a solution.  In other words, as they work through the problem, developers begin to understand the core tradeoffs at the root of the solution, including those that directly affect human experience. After all, developers, despite stereotypes are humans too.

Invention is the process of software development and it has overtaken the world. 

Share your thoughts on this with us below!


Popular posts from this blog

All good things...

Why scrum? The "how to" of development teams in sync and in tune