Efficiently shipping Big Hairy Audacious Software projects

I recently transitioned into a full-stack role – I wanted to stretch myself and step out of my comfort zone. The biggest challenge was my struggle to quell the quite nagging voice in my mind screaming ‘impostor!’.

So I got a couple of Big Hairy Audacious Software (BHAS) pieces dropped on my plate and that experience motivated this post; after all who doesn’t want to get better at delivering BHAS projects? My style of working is to consciously take notes as I run into issues, ship software pieces or meet milestones. The introspection typically involves 3 questions:

  • What to avoid

While shipping some feature, I implemented some shared parts in the common library. Unfortunately, that caused a lot of dependencies and significantly slowed down my development speed. Learning? Implement the shared pieces in the same library and do the refactoring as a follow up task.

  • What to repeat

Typically hard-earned lessons, for example, having to debug issues in production quickly showed me what good tracing information should look like.

  • What to improve

The middle ground, things that went well but could be improved. This is mostly driven by notes I keep while developing.

So thoughts so far.

1. Define the end goal

A BHAS project contains a lot of ambiguity in addition to the technical challenges involved! A sample task might be to implement a usage tracking system for ships.

The first question should not be ‘how do I start’ or ‘where do I start from’; rather I’d re-frame that to be ‘What is the desired end product’; what does a successful launch mean? Having crisp targets and communicating those to all the stakeholders is very essential as it helps to set the right expectations.

Furthermore, once the success metric is known, then it becomes possible to breakdown the BHAS into smaller more manageable chunks with less ambiguity.  Once done, order this list and put the tasks with the highest impact at the very top; why? The Pareto principle (also the 80/20 rule) implies that a few of these tasks would provide the highest importance and value. So if you don’t get the lower tasks done, it’s still a win.

2. Take small measured steps

A favorite quote of mine:

How do you eat an elephant? One bite at a time!

Assuming you picked up the most important task to work on and are still stumped. Start with the simplest easiest thing you think will help you wrap up that task – it could even be creating a branch or implementing some simple helper function.

Why this is important is that it sets you on a roll and helps you to build momentum. The more micro-tasks you complete, the more confident you are and the faster you accelerate towards ‘cruise speed’ (aka flow).

3. One thing at a time

I have tried in the past to multi-task; on such days I would feel like I did a lot of work yet deeper examinations would imply low productivity. There are two theories that come to mind:

  1. My brain convinces me that rapidly switching is more efficient and productive.
  2. Same brain convinces me that it is possible to simultaneously do two mentally intensive tasks.

No, humans can’t multi-task; rather our brains do rapid context switching. So if you think you can carry out two very demanding tasks then you either have two brains or are losing ‘brain cycles’ to rapid switches.

Another illusion to watch out for is the effect that confuses ‘busy work’ with being ‘productive’; no you can be busy (answering emails or chatting etc) without being productive. Now, I try to do one thing at a time with full mindfulness and the results have been more meaningful outcomes.

So if you are working on a task, concentrate all efforts into finishing that task alone. When you are done or if you get blocked, then you can consider jumping on a parallel or orthogonal task.

Staying mindful is also quite difficult as there are lots of distractions – consciously evaluate if you need to be in that meeting, that discussion or reply to that group email.

4. Be persistent

Once you’ve picked a task you should stick to it. Ideally any task you are working on at any time should be the one with the highest projected value returns (think weighted graphs).

Sure there might be difficulties but instead of skipping around you should dig in and solve the challenges. Ever wondered why you only get the urge to check email only when a tricky question comes up? Aha, it’s the brain trying to ‘run’ away. Don’t check that mail – your brain is just seeking a way out. Give it all your best and push until you get a breakthrough.

5. Don’t seek perfection and ship the first rough version

No writing is perfect in the first draft; rather you get your thoughts out and then do a number of passes: cleaning up typos, grammatical structure and style in follow up sweeps. The same concept applies to writing code too.

I remember trying to beautify my code and write loads of redundant unit tests while building a particularly tricky interface. I wanted the first version to be perfect. Know what? Most of those unit tests got deleted when the feature was completed.

If you are trying to build a prototype to test how something works, it is ok to be loose with rules since it’s going to be a proof-of-concept. Once you have that done, you can then design the system, implement it and add tests.


I hope these help you to deliver better software more efficiently and faster. Again, this can be summarized in the following points:

  • Define what the finished product is
  • Break it down into chunks
  • Ruthlessly focus on delivering the high-impact tasks – don’t multitask!
  • Deliver fast, eliminate all distractions.

Do let me know your thoughts.

8 thoughts on “Efficiently shipping Big Hairy Audacious Software projects

  1. Another excellent article. A few comments: Don’t deliver the first draft if it can launch missiles!

    Getting sign-offs, even on a small project, can be difficult, so it’s way more important on a large project to have a fairly precise definition of what “done” looks like.

    Introspection – three things: What’s the third?

    Like you said, things can change a lot between the initial specs and the final product, so concentrate on the core functionality first or maybe on some basic UI stuff that the user can see to be sure it’s really what they are looking for. Once you have the “right” thing, then you can make it “better”. It’s really easy to get trapped making the wrong thing better.

    Stepwise refinement is the way to go on many projects (arguing for early and multiple deliveries). Once a product is in use for even a very short time, the users start to assume it as a baseline and find all the things it can’t do or should do better. Those things are usually more important than making it slightly more efficient or polished. This usually goes on forever. Hence, the importance of the previously mentioned sign-offs!


    1. Hey Joe, always a pleasure to read your thoughts – they are always rich with insight.

      Well, I don’t work in such critical fields so I am safe delivering software that might break in preview : ).

      The third question is ‘things to improve’, areas that were ok but can be improved. I like the concept of stepwise refinement and rushing it to users who are afterall in the best position to say what works and what doesn’t.


  2. Jazakallahu khayran for another awesome piece. You should be preparing to compile all these your experiences into a book oo.
    I’ve gotten no better software development advices except from you.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.