During the last 20 years I’ve designed many applications. In the late 90’s my job was to develop functional specifications, resulting in writing long documents that were given to software engineers who would write other more technical documents.
I remember endless meetings during which we designed the model of a database based almost purely on intuition. We made assumptions based on assumptions in order to cover all the possible scenarios. We interacted very little with our users. We barely considered the interface and it was assumed that it would be necessary to write a manual to explain how to use the software.
The work cycles were long, the error rate was high, and users were often unhappy with the result. It sounds incredible but this approach is still widely used today, especially in large companies. I think the below image demonstrates this pretty well:
Agile methodologies have been established precisely in order to solve this problem, prioritising:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
Methods, processes and tools have transformed software production, making it simpler and more accessible for everyone. Today, thanks to bootcamps, twelve weeks are sufficient to learn the basics of programming and start developing your first projects independently.
Zero-Time Design vs. Design to Learn
For many applications the design time has been compressed to near zero, often being replaced by a variety of intuitive tools. For example, today almost no one designs and develops their own CMS or ecommerce system – it’s much more convenient to choose a solution like WordPress or Magento.
And for the most complex applications that don’t have a simpler alternative tool? My approach is very simple: “stand on the shoulders of giants”. Many problems have been addressed; there are thousands of excellent professionals documenting their findings and experiences; you can browse many collections of examples and patterns. Not using these resources means that you didn’t understand something fundamental: any project (not only software development) is a sequence of hypotheses, discovery and learning.
When tackling a new project, you need to optimize for learning. To do this, you must start by making a list of what you already know and what must be discovered. This way you can focus your resources where they’re needed.
If I need to make a registration and login procedure it makes no sense to invest my time into designing it from scratch; I can simply consult one of the many pattern libraries like PatternTap and choose the one that fits best for my context. Even better, you can use a tool like Stamplay that provides this kind of feature out-of-the-box.
This approach makes even more sense when you’re building a complex project such as a new product. Some years ago Thomas Thwaites wanted to make some toast, so he started building a toaster from scratch: the results are hilarious and are documented in the book The Toaster Project. Imagine adopting the same approach with you software project!
There’s an illusion that creating something new can be reduced to a two step activity: design + construction. In reality, you often start with assumptions and you learn along the way. The diffusion of this awareness is the major step forward that was made with agile methodologies in software and with the Lean Startup in the creation of new companies.
Optimize for learning
So how do you optimize for learning? It’s easy: just adopt agile methodologies. They’re made for this, right? Or just read Lean Startup by Eric Ries and other books that have a title beginning with “Lean”.
…maybe! The reality is that it’s very difficult because the propensity to learn is above all a cultural issue.
In the classroom there’s a professor who teaches and an audience who listens. The space for experimentation and discovery is small since knowledge is transmitted from top to bottom. Most of us learned in this way. Maybe there’s no better way…
Even within a company, the learning needs of employees are resolved with training courses in which an expert teaches and the audience listens. In most cases, there is nothing more than that and if you think about it, it’s pretty insane because the real learning begins when we start to use the methods, processes and tools that the instructor has described during lesson.
And, probably, being aware of this obvious (but not so obvious) truth is the first step to optimize learning. The second step is: ask yourself and your team what you learnt today and what you need to learn tomorrow. The third is: play and experiment every day with something new.
This the second post in a series of thoughts about software development and productivity. I’m not a programmer, but I’ve worked with programmers for the last 20 years in a variety of roles. View the first post here.
This post was originally published on Stamplay Blog.