Researching and planning a web application

Sep 30, 2013

Table of contents:

1. Why is Waterfall Development bad?
2. Why is Agile Development good?
3. My initial project research
4. The advantages of being a jack of all trades
5. Conclusion

Big projects are notorious for going over time and over budget. When you start out working on a big project, it’s usually almost impossible to give an accurate estimation of how long it will take to complete. This is because there are just too many variables and unknowns at the outset. Hitting just one roadblock or discovering something later down the line can have a huge impact on how the project is delivered.

For a long time software projects were developed using the Waterfall model. However, today you are more likely to see Agile development being practiced as a form of Continuous Delivery.

Having the skills to design, develop and build web applications are all very important, but you should also be able to effectively manage a project from the initial brief to project delivery.

In this post I’m going to look at how to manage a web application project and the process that I usually go through at the start of a big project.

Why is Waterfall Development bad?

Waterfall Development is a sequential process where you progress through each stage of a project plan from conception to delivery.

Although Waterfall is a dying relic in the software development world, you will likely still encounter it if you happen to end up working with bureaucratic organisations.

Typically a Waterfall process will flow along the following steps:

1. Requirements
2. Design
3. Implementation
4. Verification
5. Maintenance

The process flows from the first stage down to the last, hence the name “waterfall”.

The problem with Waterfall development is, it is extremely hard to fully appreciate what the future requirements are ahead of time. This makes it almost impossible to fully complete a stage of the process and move on to the next one. As a big project progresses, stakeholders will often come and tell you that their requirements have changed once they start encountering additional problems.

Waterfall development also emphasises fully implementing a project before delivery. However, the assumptions you made during the initial phases of the project are often disproved once the application gets into the hands of it’s users. By this time it is usually too late and too costly to go back and redevelop.

Why is Agile Development good?

Agile Development promotes rapid and iterative development where a project evolves overtime inline with feedback from the customer or end user. Incremental development is usually broken down into 2 week sprint sessions where cross-functional teams work on a chunk of the project to deliver to the end user.

The benefits of Agile Development are that the end user will be able to see working software much quicker than if Waterfall Development had been chosen. This means they can give feedback on how the project is progressing and the risk of making assumptions or an evolving specification is massively reduced.

The real benefit of Agile development is that you no longer have to try and predict the future at the start of a project. Splitting a project down in to 2 week sprints allows you to deliver the projects in small chunks so the specification can evolve based on real project learning. This means you won’t get to the end of a costly development with an application that is useless to the end user.

My initial project research

Usually before I begin a big project like this, I like to brainstorm ideas to the following questions.

To me big projects feel like the game Civilization, where at the very start you are just a small dot in the middle of a big dark map. It is only over time as you start exploring the map that you learn of the dangers and the opportunities that you will face.

By doing this early exploration, you can significantly reduce the dangers and make quicker progress on the opportunities you will encounter along the way.

What is the problem I’m trying to solve?

Before you begin the project, I think it is important to nail to one very specific problem that you are trying to solve. If you find yourself saying “X and Y” then you need to cut down the scope of what you are looking to build.

With projects like this, there should be a clear defining line around the one action you want the user to take. When you start with too many features of possibilities in mind, you will end up with a bloated and confusing product.

What are the main actions?

Where will your users be spending the majority of their time. If you have constrained your features down to the bare minimum, there should be one screen where the user should be interacting the most.

This is the main screen of your application and so the majority of your attention should be focused on getting this right. A good sign of a confusing application is where there are multiple “main screens” because the project has many primary objectives.

How can I reduce complexity

You should have already distilled your idea down to one clear objective, but how can you reduce the complexity of your proposed implementation even further? This focus on simplicity might seem like overkill, but trust me, it will ensure that you don’t get bogged down on implementation details once you actually start building the project.

For each of the features that you have planned, how can you reduce the options down to the bare minimum? Instead of giving your users endless choice, would it be better to restrict the choice down to one option? Are there any features that you can cut altogether?

Remember, you can always add additional features once you start getting feedback from your users. It is much harder to rip out half-baked features later down the line once you have already wasted time on them.

How do I onboard people successfully?

How will you make onboarding as simple an intuitive as possible? This includes registering and logging in for the first time. Whilst you will automatically be a pro-user at your own application, it is likely going to be confusing to a new user who is experiencing it for the first time.

Your goal should be to specifically design this process to be as simple as possible.

How do I prevent blank screen problem?

How do you plan to prevent the blank screen problem? This is where a user opens an application for the first time and is greeted with an intimidating blank screen.

This is a problem for both Consumer and Enterprise applications and can be the kiss of death for users who will likely never come back to give your application a second shot.

The advantages of being a jack of all trades

You might be thinking, “We’re 23 tutorials in to this series and you’re only writing about this stuff now?”. Yeah I know I’m a hypocrite for not writing this at the very start of the project, but I felt it was important to jump straight into the Laravel stuff to build up interest for Cribbb.

However, I also think that it shows how much of an advantage you will have if you can be a Developer, Designer and a Project Manager all wrapped up into one. One of the key characteristics of Agile Development is Cross-functional teams. However, the problem with working in teams is, as you add more team members, the rate of communication will rapidly drop.

If you can perform the roles of multiple people on your team, you will be able to work much more quickly. An example of this is when you are planning or designing the project, you are already well aware of all the development requirements, technology possibilities and how you should implement it. This is a huge advantage over non-technical people because you will face much fewer surprises or situations where you have to rethink an implementation or design.

Conclusion

The goal of this series of tutorials is not simply covering how to use Laravel. I want to teach you how to create a product. Learning Laravel 4 is just one step in the process.

Over the next couple of weeks I’m going to start covering some design workflows and some front end stuff.

I will then jump back into Laravel to tie up some lose ends and then start pushing ahead with actually developing and shipping Cribbb!

Hopefully this series is much more than just “Learning Laravel”, I want you to be able to take an idea and create the full online product yourself.

This is a series of posts on building an entire Open Source application called Cribbb. All of the tutorials will be free to web, and all of the code is available on GitHub.