In defense of "making it up as you go along"

Why it’s one of the greatest development processes of any age.

Related posts:


I confess – I’m for it. And I’ll go even further – I think “making it up as you go along” is one of the greatest, and most important processes of any age.

No great explorer set out with a detailed set of explorer guidelines. They adjusted and discovered.

No great inventor set out with a detailed set of inventor guidelines. They experimented and adapted.

No great leader set out with a detailed set of leadership guidelines. Leaders point the way and rally followers when their faith fails.

“Making it up as you go along” means that you recognize a good foothold on your way up a mountain and know how to take advantage of it (in other words, you understand your craft). But you don’t need (literally) a step-by-step instruction book (because you understand your craft). In software development terms, the “step-by-step” equivalent is a requirements specification. Kind of like paint-by-numbers for would-be Rembrandts who don’t yet know that method is incapable of producing genuine art.

As good as your tools?

One of the things I hate most about our industry (the web industry, the UX industry, the IxD industry, whatever), is the penchant for folks with too little imagination and too much process training, to force “development models” on us. We have “mental models” galore. We have “process blueprints” en masse. Sadly, we have a myriad of tools, but not always the proper skills.

There’s a Danish expression common to craftsman: “A worker is only as good as his tools.” Granted, good tools are critical, as is a good process. But tools represent the lowest common denominator. Even with the best tools, an idiot will make a mess of things.

Agile or ingenuity?

We’re still at the beginning of an era. The web is not yet 20 years old. We are very much making things up as we go along despite excellent pattern libraries and established best practices. Anyone who says we aren’t is either a liar or a fool. Unfortunately, in the interest of professionalism, many folks are trying to legitimise their existance by formalising their work processes.

The smart tool of choice these days for software development is agile. ‘Agile’ is basically a fancy term for making it up as we go along. Mind you, there’s nothing wrong with this. It’s a good technique used by the pioneers for whom oceans are named.

In the old, pre-computer era, we call this ‘flexibility’ and ‘having an open mind.’ ‘Talent’, ‘intuition’, and ‘ingenuity’ were also once keywords. When did we stop appreciating these abilities? We have, you know…

Now, agile development is being groomed for polite society (e.g. the clueless business executives who would have insisted that Columbus produce a map showing the exact passage to India before he had actually done his discovery work). But gosh, Mr or Ms Business Leader, agile isn’t Russian Roulette. It’s not going to cost a fortune – in fact, it will probably cost less than the idiotic “requirements specification” some overpriced consultant is going to talk you into.

Which leads us to scrum

‘Scrum’ is a term stolen from rugby (which follows a wonderfully make it up as you go along kind of gameplan). In the world of software development, scrum formalizes the informal iterative agile development process. The Scrum Master is a project coordinator who presides over meetings and shepherds the team based on a set of strictly defined rules. A formalised certification course during which potential Scrum Masters learn the basic rules and mechanisms takes several days. Why is scrum popular? Well, first, it’s not a bad process. Unfortunately, scrum can be a nasty weapon in the hands of the wrong people; business execs are often comforted by processes that are governed by strict rules. Particularly those pesky, unpredictable creative processes.

How to win the game? Stay loose!

It’s not that I have anything in particular against scrum, but I have a lot against creating gameplans that don’t allow for deviation or the unexpected voicing of a sudden brilliant idea that turns the whole project on its head. Good Scrum Masters know the value of exploring new directions. My problem is with the tyrants who blindly stick to this (or any other established process); who hide their own lack of talent and creative insight behind a veil of pedanticism and false authority.

Sorry Columbus, ignore this new world of yours. Remember, your job is to find a passage to India. What will you do between now and the next daily scrum meeting regarding this project?

How many of us slavishly follow our car’s navigation when we know it’s giving us bad advice? Very few – that would be silly. And how many times have we uncovered a blatant fault during the very first usability test? Does it make sense to test with several more respondents before fixing an obvious problem? Of course not – no matter what the test protocol may dictate.

Although I’ve singled out scrum, there are lots of other processes that can go equally awry. Many companies these days are busy trying to implement Toyota’s LEAN production system, often with disappointing results. Kaizen quality management (another Toyota development) can also go very wrong – and for the same reasons Total Quality Management, House of Quality, and Philip Crosby’s Zero Defects went wrong back in the 80s; too many managers let the process get in the way of the ultimate objective. Remember, the goal is the goal.

For every rule, there are myriad exceptions. For every battle plan, there are unexpected circumstances. For every process, there are fifty other ways to do things. So, my advice is to do what needs to be done, when you need to do it. And as to the gameplan? Don’t be afraid to make it up as you go along.

 

Eric Reiss

Eric Reiss is one of the pioneers of information architecture, having written the second book on the subject. He is a two-term President of the Information Architecture Institute, and Chair of the EuroIA Summit. Eric is Associate Professor of Usability and Design at the IE Business School in Madrid, Spain, and CEO of the FatDUX Group, a Copenhagen-based user-experience consultancy with offices and representatives throughout Europe and North America.

15 comments on this article

  1. Nice write up Eric,
    Adapting to the needs of the task at hand makes a lot of sense. Use what will work best to help you deliver.

    There are a lot of things that always crop up that aren’t accounted for in some rigid processes. It’s understandable that processes are in place for certain reasons. Yet sometimes when I’ve been developing, they only feel like roadblocks.

    Something that is restricting you at each step of the way. Yet trying to influence to change to suit the needs of the project are shut down.

  2. Mike on

    So many quotes to copy into Evernote for future reference!!

    Thank you!

  3. You’re a great writer, but I think your wrong. A production process is no place for invention, creativity, or discovery. All that has to be done before production. MacDonalds’ doesn’t want creative managers, it wants managers who will do what they’re told–so each MacDonalds’ will looke the others.
    If there’s a problem with TQM it’s that nobody knows what it is. Everybody can understand Zero Defects. The only problem with Zero Defects is leaders who don’t know how to lead–set a zero defects performance standard. ZD is alive and well and working in many, many companies. ZD can’t fail, only the leaders can fail.

  4. Really enjoyed the article Eric! The continuum of improv on the one hand and extensive planning on the other is a thorny and complicated one. In the end we have users to please, but we also have clients and budgets to manage.

    I think there is a balance to be struck. There is certainly a level of planning that is beneficial to both the process and the end result: even Columbus had to recruit sailors, secure ships, and buy supplies.

    But at the same time, we need enough room to manoeuvre. We have to be able to react to changing circumstances and user feedback throughout the process, not be locked-in to a bad idea.

    In the words of legendary improver Captain Kirk, “Without freedom of choice there is no creativity.”

    Thanks for sharing this Eric!

  5. Pingback: IROAI | In defense of “making it up as you go along”

  6. Eric, we are of like mind. This universe is a complex adaptive system and the idea that we must force silly processes on it to improve it is utterly ridiculous.

    Clearly when we are talking about production of physical products there is a benefit in ensuring quality in the sense of producing a higher yield and less product defects. This does however not apply to human interaction or any other human endevaour. Zero defects in business process means that the system is frozen and frozen things are DEAD! No further improvement. The ting that is lost in the process is the human!

    I too use the principles of setting out to sea a lot. Being a captain is a lot like being a process owner. You depend on your knowledge, experience and on your team. Only to a limited amount does one depend on rigid procedures. Maybe you run some checklist to make sure you didn’t forget anything, btu that’s it.

    “The future is uncertain … but this uncertainty is at the very heart of human creativity.”
    (Ilya Prigogine – Nobel Laureate Physics)

    “You can’t manage knowledge. Knowledge is between two ears and only between two ears.” (Peter Drucker – Management Guru)

    Therefore ia propose the concept of Adaptive Process that based on a business ontology empowers the business users to create, execute and adapt all processes without long analysis.

    Don’t be nagged down by the naysayers. They are the ones that lack creativity and want to enforce their lack of it onto anyone else in the name of quality, cost reduction and enforcing compliance.

    Thanks for standing up to be counted. My point of view here:

    http://www.adaptive-process.com

  7. Mike, Josh, Tyler – thanks for sharing your insights and kind words. Josh, you’re right that restrictions can feel like roadblocks. I think this happens when the restrictions (which aren’t necessarily a bad thing in principle) suddenly prevent the team from doing what they need to do. This, perhaps, is the balance Tyler has pointed out. Although I’m not a Star Trek afficionado, I think the Captain Kirk quote is spot on.

    Dave,I can’t tell you how honored I am that you took the time to write. I had the pleasure of meeting your brother back in the mid-eighties. And the problem you point out with Zero Defects was exactly the point of my message here – watch out for the stupid managers. Although you may think I’m wrong, I agree with pretty much else you say.

    I actually discussed this with Philip after he told a group of us (about 1988) that he was so strict in his approach that he didn’t even drink a glass of champagne at his daughter’s wedding. As to Zero Defects, no, I don’t think there is much room for exceptions. But I’ve seen some deplorable implementations, particularly during the quality boom back in 1985-9. And you probably have some good war stories, too.

    But you do bring up a fascinating point about the ability to understand what these programs are about. Personally, I get TQM, but balk at House of Quality. And I have been a great promoter of Zero Defects for over a quarter of a century because it is simple to explain, easy to understand, demonstrably beneficial.

    By the way, if you have time sometime, I’d love to share some thoughts with you about how creativity and insight CAN improve a production process or service offering. This has nothing to do with Zero Defects, this is about encouraging the front line to give feedback that can improve processes and innovate. And to use your own example, McDonalds, well, the Egg McMuffin, Big Mac, and Happy Meal were all invented by local franchise managers. Food for thought?

  8. Max. Thanks so much for your views. And the Peter Drucker quote is brilliant (my great aunt was his grade-school teacher back in Vienna – he was a family friend).

    I like the Adaptive Process concept. And I finally fully understand why one of the other players in our professional market, Adaptive Path, chose their name. I always “sort of” got it. But now I think I truly understand.

    Don’t get too down on Zero Defects. Things only become frozen when ZD is applied inappropriately and thus discourages feedback and development.

    Dave, I was wracking my brain to remember where I had my McDonalds info from. A couple of searches on the internet led me back to my guru, Clayton Christiansen at Harvard. Here’s a link to a 2007 Forbes article that talks about the same stuff:
    http://www.forbes.com/2007/08/31/christensen-innovation-mcdonalds-pf-guru_in_cc_0904christensen_inl.html

  9. We get into trouble any time we try to prescribe an instance of a process over time. Consider the following concise interpretation:

    In preparing for battle, I have always found that plans are useless but planning is indispensable. — Dwight Eisenhower

    As we project our expectations farther out into the future, the probability that something will go awry compounds upon itself. One unexpected event will necessarily affect any subsequent activities that depend on a particular result. This causes ripples through the process which multiply in cost at every turn.

    The character of software and other creative endeavours is possibly the least forgiving in this regard, since there is no huge capital cost (of factories, materials, logistics, etc.) to act as a centre of financial gravity. In an industrial-age project, the cost of failure is massive, immediate, and enormously conspicuous. In a post-industrial project, failure is silent, as it is merely the absence of success.

    I see us approaching a method of production of software and similar artifacts with better than moonshot odds of delivering value. We’ve dispensed largely with prescription in favour of exploration, which is altogether a good move, but I still see two flaws that we have yet to correct.

    First, I still see a lot of fixed-bid contracts and permutations thereof. This includes equity financing and internal budget allocations, and people continue to do it even though nobody expects to actually deliver on time or on budget (minus the naïve customer! Or producer for that matter). I think it would benefit us on the whole not to obfuscate these immensely unpredictable (though not necessarily high!) costs and figure out new ways of financing these projects.

    Second, principle #1 of the Agile Manifesto is the early and continuous delivery of valuable software. In my (perhaps limited) experience, delivering software early is at best a palliative for eager management types and at worst a permanent commitment to a suboptimal and severely limiting solution.

    I should make myself clear: it is imperative that we furnish customers with concrete demonstrations of progress, I just don’t think code is always the best way to do that. I’ll go further by claiming it usually isn’t.

    The basis of my claim is that software reduces to an extremely precise incantation of a business process. Consider:

    First ask yourself “How would I do this without a computer?” Then have the computer do it the same way. — Mark-Jason Dominus

    From a decade of writing code for a living, I can attest that’s pretty much how you do it. Where it gets difficult is in defining what this is. It is important to recognize that software is none other than an artifact of extremely precise language. It is most successful when we can frame it in numerous nesting layers of language that begin broad and fuzzy and successively increase in precision.

    Merely paring down, by the way, is a questionable strategy. It mortgages the long term for the short, and is unnecessarily consumptive in its own right. I speak of course of the minimum viable product (that would be Eric Ries). As I remark elsewhere, there is scarcely anything more contradictory to the timely acquisition of valuable results than bickering and vacillating over what work not to do.

    To be sure, there is a category of interim deliverable that absolutely must be delivered as software. If we want to answer questions about feasibility, the behaviour of real data in bulk or the fitness of third-party software, we cannot avoid writing code. Where we get into trouble is in delivering something that can be mistaken for the finished product.

    I submit that if we started treating software production as a novel and idiosyncratic process, rather than trying to cram it into a paradigm of construction (or manufacturing, or gardening, or rugby, or any other metaphor), we might find even better ways of delivering even higher quality results.

  10. Pingback: Don’t be a Process Nag « cvil.ly

  11. Hi Dorian,

    VERY interesting observations. They really deserved to be an article unto themselves. Have you contacted the editors of Johnny Holland? This is good stuff.

    You touch also on the problem so many of us know: clients frequently mistake a prototype for a finished product. But as Alan Cooper rightly points out, it’s cheaper to throw the prototype code out (which is invariably verbose and poorly structured) and replace it with streamlined code now that the challenges have been sorted out. I’d like to hear more about your thoughts on this, too. But another comment to this post would probably not do them justice.

    Warmest regards,
    Eric

  12. Thanks, Eric. Last week I spoke with Jeff Parks for an upcoming installment of his IA podcast on this topic and numerous others. I’ll talk to Jeroen about your suggestion.

    I think in software we treat code as sacrosanct, and that a bad implementation represents completed work and therefore would be a waste to throw away, no matter how flawed. We forget however that it is exclusively an artifact of language, and is immediately derived from the mental model of its author. That somebody understands a given problem is infinitely more important than any particular incantation that professes to solve it.

    As a practical litmus test, compare software with a legal contract, a piece of music or a diplomat or politician’s speech. In any of these artifacts is it more important that they are right or that they are right now?

  13. Dimiter Simov (Jimmy) on

    Eric, I like what you say and agree with it to a large extent. Yes, we have to be flexible/agile and snatch any good chance for improvement, faster delivery, or whatever. We also need to plan, the trick with the plan is to re-plan often and change the plan along the way. I guess this is what you mean by “making it up as you go along”.

    I have a problem with the statement that detailed requirement specifications are bad. No, they are not. Not following or not implementing the specifications is bad.

    I work as a interaction and interface designer and have seen how not implementing the specification makes the product or a certain feature less usable than intended.

    I know that the minor details can make a product feel usable, so I pay attention to such details. Developers, or coders, on the other hand think about things, such as code integrity and performance. The interaction details are beyond their mindset.

    A small example. We have a product that allows users to set relations among records (like people and companies). When users want to set a relation to an item, they click a button to open a form where they select the item to relate.

    The developer has to open a form. She just opens the form and forgets to put the focus in the first field in the form where users type the name they want (despite the specification). So users have to click in the field first (or tab to it). This does not seem like a big deal; however when users have to do it many times a day, they lose precious seconds that pile up and eat out their productive time.

    If we do not have a specification, the testers will not know that not having the focus in the first field is wrong. Since we have the spec, testers file a bug, and the developers fix it.

    Do developers learn from the experience? Not necessarily. Remember, their mindset is different. I have seen this particular focus-not-in-the-first-field bug filed several times.

    Cheers
    Jimmy

  14. Pingback: iPad – Breaking Free Of The Trading Desk « Tales from a Trading Desk

  15. Pingback: links for 2010-08-02 « Boskabout