Developing software is a lot like cooking. Specifically, it’s like slicing and peeling an onion. At every turn you peel back layers and layers of details, complexity, and possibilities. This is true because ideas are a lot like onions and all software projects start with an idea. Let's see how this onion analogy plays out for us when it comes to software development.

Finding The Idea | It Starts with Picking Out Your Onion

Just like most endeavors, you begin your software development project with a round idea of what you want to achieve, even if it’s just a vague notion. Once you settle on the idea you want to pursue and invest in, you then start the slicing and dicing to uncover more information. You begin peeling back details upon details of how executing on your idea in a specific way will actually fix the most important problem(s) you are trying to solve. You begin cutting into the core of what you are trying to achieve and you start asking the hard questions:

   
• Why am I building this and who am I really building it for? What are our main motivations behind building this software? What specific problem(s) are we aiming to solve?
   
• How will we know we've succeeded? What will our KPIs be and how will we know when something is actually done and ready to ship?
   
• Does an existing system already solve this problem and do we really need to build our own?    If so, what are these competitors or peers doing well or not doing entirely that you could build on? What's your unique value proposition?
   
• What's the problem behind my problem and why do I need it solved? How much of the solution do I need and what can I live without?
   
• How will you acquire users and how will you retain them?

These questions are really an example of good due diligence and product discovery. Before any investment of time and money, you should ask yourself if you've done enotugh research to properly mitigate all of the known risks and potential downsides. At Smashing Boxes we look to rapid prototyping and design sprints to help in this and to tackle big problems before we actually begin building and architecting a software product. This helps us in a number of ways but here two important ones:

   
1. It helps us co-create a unique value proposition focused on actual users.
2.    Through tools like Sketch and InVision we can create rapid prototypes and visual artifacts to test ideas and validate core features and functionality. These testing sessions will inform you and us on what really matters and what you can live without. In short, it gives us a common vision to work from.    
3. These designs and prototypes will serve as guideposts for development and help the team get on the same page. It’s important to remember that these designs are not specifications and subject to change as more is uncovered in development.
   
4. It gives us a better framework and starting point for estimating.    Estimates get exponentially more accurate when you have more to work from in the form of known requirements, user stories, a product roadmap, and wireframes.

Estimating The Costs | How many layers are in this onion and is it big enough?

This brings me to my next point. Estimating is tough. If we're continuing with the onion analogy, estimating and scoping a software project is a lot like estimating the number of layers inside that unpeeled onion. It's an inexact science and you have to be careful of hidden costs. But after you peel back a solid variety of onions you will likely get better and better at estimating, but you'll still have some margin of error to manage. This is important to understand so that you don't look at your timeline and budget in a naive way but rather evaluate it strategically and always remember they are just estimates, subject to change as more details are uncovered… One of the best ways to help in sizing the project is to do some user story mapping and release planning early on to understand and break down concepts into smaller and smaller pieces.

Planning for Development | Don't let the onion burn your eyes...

Cutting an onion invariably makes you cry. Hopefully, software development doesn't have the same effect. But if you think ahead, you can prevent this. You can wear glasses or goggles or you can try soaking the onion in water.

In the world of software development, wearing glasses or gloves to chop onions is akin to setting up a good project cadence and doing enough planning and design up front and along the way to avoid the tears as well as skirt building a kludgy product. At Smashing Boxes our modified agile approach help us maintain flexibility and avoid the tears. Here are some of the must have planning steps I recommend to prevent those software development tears and ensure success:

   
1. Co-define a definition of ready and done as a team.
2.    The Product Owner and QA person should lead this effort    
3. Involve QA early and often in the project and have clear stated definitions of done for accepting features as complete.
   
4. Research product alternatives and benchmark the competition before you start the project.    This helps you breakdown your unique value proposition and uncover your product strategy.
   
5. Design a prototype and test it with real users.
   
6. Create a product roadmap to provide a milestone based timeline.
   
7. Write user stories and acceptance criteria as a team.
   
8. Co-create a release plan based on the set of user stories, epics, acceptance criteria , and overall product roadmap.

Executing on Your Plan | Or the Art of Getting Your Hands Dirty...

After a few weeks, you'll be in the midst of full on execution and development as you move forward with a rhythm of building, testing, and shipping software. This is what I like to call the “dirty hands” phase. It's the part where your hands acquire that onion smell you'll be trying to wash off days later. Here are some tips to keep your project on track during this phase:

   
1. Your release plan should inform your sprint plan.
2.    As you begin executing on your release plan, try to plan out your sprints around workflows that build on one another (start putting the onion back together so to speak). This is where the project comes full circle. As you start a project, you really begin with a lot of deconstruction exercises as you take apart your idea and start organizing common elements. As you start developing you begin putting these elements back together in the form of workflows that can live on their own but become increasingly valuable and important as the whole is completed. Try to vertically slice your product in a way that allows you to build workflows incrementally each sprint so value is created along the way.
   
3. Never forget that working software that people want is the ultimate goal. Try to release or at least demo early and often so that you can make adjustments and ensure your software works well and as expected for your end users.
   
4. Embrace that lingering onion smell.
5.    The lingering smell of a software project might take the form of technical debt, code smell, or unhappy users and/or stakeholders... You should recognize that every project is going to have some missteps along the way and some form of recurring debt. Recognizing this, you can take steps to proactively acknowledge them and make adjustments along the way through team retrospectives and collaboration exercise to minimize negative impacts and ensure success. Embracing this smell allows teams to learn and improve over time. Ideally, a team stays together long enough for these learnings to pay real dividends for the product.

Like most software projects, this blog ran over the number of lines I anticipated. Maybe I should have written it as a series of smaller posts released incrementally… Either way, I hope you learned something and stay tuned for future posts.✌ Ben MickeyWe are Smashing Boxes. We don’t just build great products, we help build great companies. Let’s chat.