Architecture through iteration
We live in a fast world and our development culture reflects that. We want our apps to be up and running as soon as possible, bug-free. Everything needs to show exponential growth, otherwise what’s the point…
How do you achieve being brief and effective in your work? What the business likes to call “efficient”… Do you gear up and try to outperform everyone’s expectations? Do you use third-party software? Do you fake it till you make it?
Answering that question isn’t as important as investigating why speed is of the essence. A quick assumption is: money. Time costs money and less time should cost less money…. right? Another guess might be: timing. You need to launch in a brief window where your product will be most effective; like a toy before the holiday season. A third reason, probably rarely mentioned but rather popular from personal experience: ignorance.
Although the first two reasons are understandable, the third may not be as obvious. It’s a known fact that programming is relatively new ground in the business world (only a few decades old) and trends swiftly change, in far greater pace than any other industry. Even technical managers might not have a good grasp of recent technologies and their best practices. As a result, creating timeframes becomes vague and setting deadlines arbitrary. One thing is a constant: the sooner the better. From a managing standpoint, that becomes the holy grail and squeezing development in less time certainly a good thing…
Have you ever wondered why thousands of people working in enterprise can’t match the creativity of a few oddballs passionate about their product? It’s most likely not a lack of talent. In most cases it’s because of the situation described above. Rushed development, managed by people that have little understanding of the underlying technology produces inferior products, consistently. It doesn’t matter if you have the best intentions; it doesn’t matter if you have the perfect vision. If you don’t execute properly you will not produce the best result; and thus fail. Because someone else will…
Which in turn invites the question: How will that “someone” do it? If our process is broken and it’s the most popular process, what is the deciding factor that will favor one product over another? Admittedly not an easy question to answer, and one that may have different answers depending on our focus. Lets assume that we’re not building cookie-cutter products, that we have an outlook for innovation. How can we expect to achieve the best result through that lens?
In search for the best solution…
When you’re building something new that’s never been done before, you can’t be certain of the architecture beforehand. You have to try things out and see what works and what doesn’t. That takes time. Immediately, speed is out the window. Instead, scientific analysis becomes the compass. Code reviewing on what’s produced provides the information we need and the experience propels us towards better revisions. Lets elaborate.
Experiment
Being able to iterate is essential. Agile is a popular practice that’s been mostly ineffective in an enterprise environment because it implies a quality in the development process that is often abused by opinionated managers to get their own way. Agile does not mean flexible or debatable. A solution does not change if it can’t be improved, and labeling something as “better” needs to be undeniable and not based on biased opinion.
Agile at its source is about experimentation. Making little demos that most of them will go nowhere is fine. Focusing our attempts on one idea may seem more efficient but might lead us away from the “best solution”. It doesn’t matter if something is broken. The real question here is if it’s structured properly. Given that, we know that once it works it will be high performing and stable.
Almost like in a Darwinian scenario, later generation apps benefit from the mistakes made in older, lesser performing apps, with broken functions in some cases. On the flip side, not navigating away from the set path and making our app work with “sticky tape” will satisfy the non technical people but will come back to haunt us forever. A lot of “bad” software exists because of this short-term, quick win, mindset.
Recycle
Creating good code is only half the battle. Creating reusable code is an art form of its own and the practice can greatly help us in our search for the best solution. If that association does not seem obvious, lets fast forward to the following claim:
Building 100 apps is easier than building 1 app
This is one of those statements that at first sight seems ludicrous and may even harm my credibility by saying it. We are conditioned to think quantitatively and we all know that 100 is bigger than 1. So why the foolish claim?
When you are developing one application at a time, you are focused on your idea/product. As a result, you either:
- create ad hoc solutions for your particular needs or
- you are replying on third parties for a number of internal components.
The first strategy will generate a lot of code fixed for one purpose, to support your application. This code is doomed to live an die with the application itself. The second strategy offers the benefit of reusable code but incompatibility between the individual components and the custom application logic might feel at often times like fitting a square peg in a round hole. Practically speaking, a lot of the headaches during debugging relate with this incompatibility, while we’re pushing software to do what it wasn’t designed for.
Imagine building 100 apps like that and it may rightfully seem impossible. Managing the independent dependencies while fighting for maintainability and future support can drive a person insane. How can this possibly lead us to the best solution? Instead, lets imagine a process where we’re working with a lot of concepts in parallel. Creating abstractions of common components and making design decisions that will provide a uniform API between them will guarantee each application has only the custom logic it needs to and we won’t have to recreate the same thing twice. Recycling code saves us time and effort in the long run and organizing our development process like that might lead us into multiple directions simultaneously.
Care
We’ve covered how to work and how to organize our work, but what about our state of mind? Innovation requires drive and that is usually tied to the urge of racing towards the finish line. If we operate as described, de-prioritizing execution speed while experimenting, where will that drive come from?
I like the metaphor that application development is much like gardening. You have to let the apps do their thing but at the same time pay close attention to their state and intervene if there’s something wrong. Some apps might need tweaking or pampering, others are more stable for the long term and you just get to appreciate the fruits of their existence.
Treating our code like a garden, that continuously lives and breathes and requires our ongoing attention creates a mindset that includes maintenance as part of the development process. If we truly care about our applications we have to give them time to grow… And maybe the “best solution” arises organically by promoting what works and scrapping what doesn’t, much like nature itself. Being present in the process and setting our priorities straight will allow us to operate in the long term with a constant pace instead of aiming for the short-term goals.
Caring about the quality of our product supersedes speed in the execution and effectiveness should not be measured in “time vs tasks” charts. Creating long lasting code that will outlive the lifecycle of one project is an achievement in its own right. It’s the legacy we leave behind. And leaving an awesome legacy is when we are truly efficient.
