When it comes to product development, is code the first thing that’s done? When are the features defined and the risks evaluated? What about deployment, should it be planned before the software is finished or after?
These and other similar questions reveal the complexity of the processes involved in product development. The better your comprehension of what each phase involves, the better you can deliver what is expected.
In this series we will cover the entire software development process, starting from planning and ending with maintenance. The focus will be what the process is, who is involved (some steps don’t require the developer), and what you should expect/do as a junior or midlevel developer.
This first part of the series will explore the first two steps: planning and analysis. Our goal is to define the purpose of each step, determine the parties involved, and identify your own roles as a junior or midlevel developer. Naturally, this process varies from company to company, so we will tackle a few common scenarios for teams of different sizes.
Planning
To clarify, “planning” here refers to a software product: what will be built and the processes with which it will be built, not to the implementation of a specific feature.
Building software is complicated. Developers need to write code that adds functionality, doesn’t have many bugs, is easy to read and debug, is maintainable and easy to change, follows conventions, etc.
Furthermore, the system needs to have a 99.99% uptime while being secure, protected and well optimized, there must be reliable data backups, and the user experience should be pleasant. If the software product is to be successful, the features of the system must be planned and researched from a business perspective.
Unfortunately, planning the features and processes is one of the most overlooked aspects when developing a product, even though it determines the goals and acceptance criteria of the entire project. Failing to decide exactly what to build and to choose the correct processes for work can end up costing a significant amount of time and money.
The key is what will be built; focusing on the end goal, not how it will be built. On paper everything is cheap and easy to build, but in reality this is not often the case. It is important to keep in mind the throughput of the team that will work on the project.
Keeping the Team in Mind
You can’t realistically build a game engine that will be competitive with the current ones with just two people. Yet, if a project is not ambitious enough, it is likely not worth building. If we take the startup scene as an example, safe projects aren’t the ones making the big money—in fact, they are rarely the ones that survive past the first three-to-nine months.
There is a very thin line between choosing the right number of business-critical features that will set up a product for success and having the product fail because the development team can’t deliver the product with acceptable quality.
As you can see, planning is quite tricky. Since this part of the process is mostly about the product developer, asking software developers for their input is usually quite limited. Unfortunately, a lot of seasoned developers (with respect to the company) will get less ambitious and more conservative over time with regard to new projects and features.
Why this happens is a very long discussion. The gist is that some people don’t want to overcomplicate their current job, others become lazy over time, and finally some have seen how ambitious projects have led to lots of unpaid overtime and stress in the past and aren’t keen on going through this process again.
Other Features and Factors
Depending on the company size and structure, different people will do the planning, but other than the features, there are several factors that must be decided on:
- Rough time slot for development. How much time will be spent, when it should be released.
- Definition of “done.” What is expected to be delivered as an end product.
- The team building it. In big companies, entirely new teams can be assembled for this process alone.
- Risk assessment. Some of the risks, usually the most crucial ones, should be considered.
Your Role in the Planning Process
For big companies, developers usually won’t be brought into the planning or the design, as the planning is nontechnical. For small companies, it is highly likely that a lot of information will be public or openly discussed.
As a junior developer, most of the time you won’t know what is planned. If by chance the company is transparent and information comes to you about possible projects, the best thing you can do is to focus on your current tasks, delivering as much value to the company as you can.
Even though it may be tempting to ask around and make suggestions, this is out of your domain, and the hard truth is that as a junior, your ideas will almost certainly end up wasting other people’s time.
I’ve been there multiple times, and looking back, I can understand why people have been short with me. Let the business figure out what will make money. This is their responsibility, they are best suited at it, and they should take the blame if it fails.
Focus on your current tasks. Do not sabotage current projects by redirecting your time and energy at something hypothetical. Most projects (ideas) are scrapped way before development. Usually, there are too many risks or the resources required make for a questionable return on investment.
If you are a more experienced developer, you should first make sure that your tasks aren’t falling behind. If a project’s planning is getting serious, you may want to do a bit of research on some technologies that can help you if you are building a project. For instance, what technologies already exist on the market, and what do they use?
Even though it’s usually architects who do the design of the system, the opinion of experienced developers will always be cherished in good companies.
The size of the company will usually dictate the formality of the process and often enough the transparency. Usually, the bigger the company, the more strict people are with all sorts of knowledge, so in a lot of cases, when you are working in a big company, you won’t really know what’s going on behind the scenes and what is being planned.
This isn’t necessarily a bad thing; it’s more of a policy rather than intentionally wanting to keep people in the dark. It’s not like knowing the future projects of the company will help you finish your current work faster, and it can even demotivate people if the upcoming projects are boring.
Be pragmatic, do your work first and then contribute elsewhere.
Finalizing the Planning Process
The final thing that is usually decided upon is the supporting software: the bug trackers, wikis, and maybe some processes like sprint duration.
It is important for the supporting software to help the team, not waste their time. All too often complicated supporting software is chosen that has a high learning curve, takes a lot of time for the developers to get used to, and ends up hurting the product instead of helping.
Now that there is a full-fledged idea of what should be built and how it will be monetized, we need to thoroughly evaluate the product both technically and non technically.
Analysis
So far, the sum-up of the product we are building may sound like:
“We are going to build a platform for local meetups for X. We are going to offer accommodations through a partner program with local businesses—primarily restaurants and cafes, so the meetups can get special offers and local businesses can gain new clients. Around 10* people will work on the project, using scrum with biweekly sprints.”
(*10 is a ballpark estimate. More or less people may have to work after the analysis phase.)
The features need to be defined as thoroughly as possible so the design can be made accordingly. We are human, we make mistakes. It’s normal for certain features to evolve in time and to change, but every change increases the time and cost it takes to build the product.
Defining Features With User Stories
One of the most common ways to start defining features is with user stories. A user story is a diagram, a drawing, or sometimes even text that describes one or more user actions. These actions are usually the first features that are built. Even if you can handle 10,000 requests per second, it’s irrelevant if your users can’t use the software.
Let’s go back to our example for the local meetup system. These meetups need to be organized somehow.
Let’s write a couple of user stories and see what features we can derive!
The user logs into the system. He creates a meetup and sends invites to some of his friends.
As you can see, this user story explains what the user does, but if we had to design or implement a system on this, it isn’t particularly useful.
Think about it. How will the user log in? Do they have a registration in the system? If so, is it a username or an email? What about Facebook or Google logins. Are those supported? All we know is that the system has users. We already have all these questions, and we are only in the first sentence of the user story.
What should be done here is to carefully consider what types of registration the system should support. This is a complicated process, as there are a lot of factors to consider. Is the targeted user base using any of these platforms? Is it legal to use it? What will happen if the platform we use for authentication decides we can’t use it?
Let’s say we’ve done our research and will go for having a Facebook login only. We can then rewrite the user story as:
The user logs into the system via Facebook …
If we support multiple login ways:
The user logs into the system via Facebook/Google/our own login …
You can add here as many details as you want as long as the user story describes user behaviour and not system behaviour. An example of a bad user story is:
The user logs into the system via Facebook A request is sent to our system backend that starts a new session.
There are two main views on how detailed user stories should be:
- As minimal as possible
- As detailed as possible
Use whichever suits you. Personally, I prefer to have details, but I understand the argument that having to read a few sentences filled with details is daunting and annoying at times, especially if you want to have an overall feel of what the user can do, not how they can do it.
Finalizing the Analysis Process
The analysis process usually ends when user stories are created for the majority of the user actions and most of the high-risk decisions have been made after being researched and analyzed.
Although the process is usually the same for most companies, the people who do the work may be a single team, several teams, or a single person. The user stories may be in a pdf or drawn with software, pictures from a white board, or even post-its.
The artifacts aren’t that important. What’s important is to have decided on the functionality so the architecture of the system can be done correctly.
From what I’ve seen in big and small companies, the difference is usually in the formality of the artifacts. The bigger the company, the more people need to see and approve the artifacts, so it’s better if everything looks polished. In a startup with a few people though, a few pictures and pieces of paper will be more than enough.
When you see user stories as a developer, regardless of your experience, it’s good to ask yourself as many questions as you can to make sure there aren’t any major unknowns that may cause delays to the project.
You have to do this, not only because you are a good employee but because if you left something huge slip, it would not be entirely management’s fault when the overtime comes. This is the most common and most crucial mistake that’s made and can lead to anxiety. Do your best to avoid it for everyone’s sake. Don’t get me wrong—it is proven that estimating is not an exact science, but losing time with your family and loved ones because of a mistake that could have been avoided is one of the things that stings the most.
The Cost of Skipping These Steps
Without proper planning and a thorough requirements analysis, the project is bound to fail. It has little merit if the artifacts of these steps will be well-formatted pdfs or a few sheets of paper.
What matters is to invest enough time and involve enough people to get the precise processes, user stories, and requirements so the software can be designed, developed, and deployed within the given timeframe with acceptable quality.
Remember, planning and analysis are processes usually made by the business part of a company—analysts, business developers and the like. Their job is to find the problem and solution, find the market, and evaluate the risks. Although being part of the process may be tempting, the best approach is to focus on your current tasks and raise any concerns and suggestions you have toward the end of the planning, analysis, and risk evaluation.
The supporting software and processes that will be used while building the software must help the people involved. If a process or tool puts a strain on its users, it should be changed.
Published on Java Code Geeks with permission by Zlatin Stanimirovv, partner at our JCG program. See the original article here: The Modern Developer Part 1: Planning and Analysis Opinions expressed by Java Code Geeks contributors are their own. |
