Planning A Software Project
It’s time to start a new project, from scratch. Where do you begin? Many times it starts with sketches on paper, or a conversation with other types of developers.
During a weekly discussion, the #TechMasters community shared their insights on how to properly plan a new project, and how to approach prototyping. Whether it is personal or business or you are racing for a Minimum Viable Product (MVP), here are some techniques shared by the community.
Gathering Requirements
Scoping out the project’s requirements and dependencies are essential. Almost nothing beats a notepad when you’re starting out on your own.
I like to start projects with an old-fashioned notebook to jot down the high-level requirements. I’ll go through a couple of iterations of that to make sure I cover the main aspects, and any critical functionality isn’t missing. From there I take these high-level requirements and break it down into a system diagram. My Frontend talks to a Backend, the backend uses a DB and the Internal Auditing API, etc. This helps map out dependencies as well so you can discover earlier on if any other projects within the company will be blockers. You want to raise those dependencies earlier than later.
Brainstorming on paper is great when your project serves an internal purpose, but things get trickier when evaluating a product.
User Stories
Consumer product ideas usually start with a user story, which captures what the end user does or needs to do as part of their job. This technique helps to bring out the project’s requirements and break up its scope into high-level tasks, which in turn instigates a conversation to begin the project:
Based on a user story provided by the product owner, all persons who have a knowledge of the system sit down and analyze the user story of the product owner; precisely the problem and what exactly the task is. […]
Since my product is cross-platform and web-based, which technologies (APIs) might be required and which can/can not be used for compatibility or backward compatibility purposes [need to be sought-out]. In this initial conversation, not only the people doing the actual task are involved, but also individuals who have a knowledge of the system and have the best interest of the system in mind. […]
It’s essentially a round table discussion. We all reference a diagram of the components involved and how all the pieces should come together. Once we’ve established which components this feature touches upon, we can then start scoping the high-level tasks involved in completing the actual solution. After the high-level tasks have been sorted out, we then scope out smaller tasks which can then be divided among members.
— Yan S.
If the conversation becomes excessively democratic, and there are multiple attractive ideas, this may lead to a pitching competition by the developers. In most cases, an idea is accepted for prototyping if it can be proven in under two weeks.
Prototyping
Failing fast is a technique used to discover significant discrepancies in a project’s scope early on. If there is a permissible time and budget, developers can come up with a rapid-prototyping session to see if their product idea will take off or fail fast. Unfortunately, time and budget are two big factors not everyone can afford, or sometimes the project deals with very expensive components that cannot easily be prototyped.
Community members were somewhat divided on prototyping, though the majority of participants prefer prototyping over rigorous planning. This opinion is exemplified by consumer-facing products in which:
Prototypes greatly help in early validation / invalidation of the customer experience. [Generally, all prototypes are iterative] with hopefully small course corrections along the way as your complexity increases. [I’m] not opposed to exploring architecture first, but I’d like to go in with some concrete data / examples so to better design the architecture around, hence prototyping.
One advantage of prototyping with code is the accessibility of Git code reviews. With daily pull requests, a small team could quickly tell when something is heading in the right direction as much as several times a day.
Prototype-First Planning
On the stronger spectrum of prototype favoritism, we have an appealing story where a prototype-first plan may lead to a win-win-win situation:
There are usually some high-level principles that the team is agreed on. We don’t do any detailed architecture or heavy requirements up front because then everybody knows the least about the problem and most of it ends up changing as you go. We choose to delay decisions to the latest time possible and allow for prototyping and experimenting to identify what you will actually build. All of this is considered “draft” code just like before putting together a presentation or a proposal you start with a draft to get all your ideas down, and then you edit and edit and edit.
I think building up towards a solution is a better approach that allows you to learn more about the problem vs. breaking down the problem into smaller problems and then solving these more minor problems in hopes that that big problem will be solved, too. Building up towards a solution means you try many different approaches, and you aren’t restricted by an outdated architecture diagram or a requirements document that you put together at a time where you knew very little about the problem.
We start off with a high-level objective that we think we want to solve for. Over time, that too can change as you understand the problem more and your perspective changes. I am in the camp that most software development is more art/craft than science/engineering. So I like to get stared with “painting” on the “canvas” as fast as possible and start exploring options and refining early ideas than paint myself into a corner because of these early ideas. As for these managers and stakeholders that think the prototype is done, it’s easy to explain that it’s not. We have draft presentations, draft emails, draft proposals, draft case studies… and we also have draft code. If they don’t get it, there are companies and teams that do.
You may have questions, and so does Leo:
Do you throw away the prototype or does [it] evolve into production code?
And so:
Both can happen. And a third option can happen, too; the prototype proves that it’s not a good solution for that problem you were solving, but it’s perfect for another problem.
— Nael El Shawwa
Also when prototyping, and this may seem obvious, don’t get caught up in chores such as setting up continuous integration, pipelines, or development environments. As Ian points out:
I once read an article about a graphic designer who started to use the default Photoshop layouts because they found they’d spend 1–2 days configuring the palettes, feel like they’d done a ton of work, but then realized they hadn’t even started on the actual design they were planning to do. You can easily get distracted by stuff like that.
Power of Majority / Enterprise-Grade Prototyping
On a large-scale team, there are many moving parts and a huge margin of error. To move a plan towards final approval, there needs to be careful consideration from everyone involved, and then a final verdict is scored. One of our members has insight on such planning:
Although high-level principles are universal, a lot depends on the team you have on hand. After a few projects and iterations, I think we figured out what works best for our team, and it’s still an evolving process.
1. Every greenfield project would kick-start with 2–3 weeks of high-level prototyping to prove the tech stack & high-level solution design we choose as a good fit.
2. While product owners work with requirements/business, technical team focus on the next 3–4 sprints (approx 8–10 weeks) of work; all architectures and decisions are geared towards the upcoming 3–4 sprints. The technical team does not commit more than 3–4 sprints as the aim is to have a working version of the product in production after each sprint, which is every team’s goal.
3. Once the high-level design is established (proven through POC), other design decisions are taken as late as possible. Architecture decisions are made one sprint ahead. Special workshops called “technical design clinics” are run by architects to discuss low-level design and architecture, and everyone is welcome to give their opinions. If no agreement is reached, then parties do a quick POC to prove their point.
4. The most important thing we practiced is to log each of our design decisions in confluence, and review them periodically (approx. every 10 weeks), i.e., basically check if the design decision taken is still valid and verify how many decisions we got right. If 8 out of 10 decisions are still valid after 6 months, then we got something right.
Hurdles
Not everything goes as planned, and not every plan…goes. Office politics was often mentioned throughout the week as a leading cause of software planning disasters. Though there were not any direct examples, I can see how red tape could get in the way of developing a viable product. Or, how not taking developers’ suggestions seriously could lead to immediate technical debt, causing the whole project to move slowly and end up in a state that is hardly maintainable.
Forecasting technical debt, in my opinion, should be a top priority in software development. Though some debt is inevitable, having a team being slowed down by poor issue tracking, lack of internal coding standards or lack of tools is something that can be easily avoided in most cases. I often recommend removing the easiest hurdles first, so that the rest of the development process can go much smoother, especially if those hurdles are trivial, free, and take under an hour to rid.
Picks
In and out of the discussion this week, we have:
Get Planning!
Do you have software planning stories to share? Tell us on Techmasters.chat! We discuss something new every week with hundreds of different perspectives and backgrounds to learn from!
