Timeless web development best practices
In today’s web development world, we are constantly confronted with new technologies and innovative methods for solving problems more quickly and efficiently.
But instead of setting up just another post about the latest javascript or PHP frameworks, I wanted to take a step back and talk about some underlying principles of web development that in my opinion have proven to be useful and persistent over time, because they can be applied to most development cycles without depending on a specific technology or programming language.
What follows are some easy to understand concepts that you can implement in your medium-sized design agency or freelance processes to accomplish a few important things that probably all of us are aware of are almost always in danger:
- Quality won’t be as great as promised
- Deadlines can’t be met as scheduled
- Project is going to cost more than expected
Requirements engineering
People usually have different expectations about a system. Most of the time, misunderstandings occur when two (or more) people have different assumptions about how it functions.
Enter “Requirements engineering". Having been an important field of software engeineering for a long time, this process helps us define proper assumptions and a more precise scope for our applications, so that things don’t get out of control during the development phase.
Defining use cases
One essential step of it is be to define all possible user scenarios of your application. Each of them represents a possible action that the user may want to take. This can easily be achieved by opening up a new excel sheet and writing down line per line what you want your users to get done.
In your concept, design and implementation phase, this list is going to back your user interface decisions and help you focus on how certain things are supposed to work – and how they do actually perform.
Most developers are familiar with the Unified Modeling language, so you might as well want to visualize these use cases in the corresponding diagram type.
Interviewing potential users
I think there is no better way to define the exact requirements of a system than actually talking about it with potential users. This can already happen at a very early stage of the analysis phase.
Since you already have a rough plan on how to put your ideas into practice and what your solution might look like, ask some people about their opinions and how this system could be designed to be more user-friendly.
In later iterations you might want to do some more profound research with the help of focus groups.
It’s mostly the non-experts and non-developers who give you the best insights because they don’t have to consciously fade out all the technical details but simply focus on what their experience should be like.
Inventing personas
As an alternative or even in combination with the interview method, you can define some imaginary characters of your potential target group.
Let’s say you have an application whose goal it is to simplify job searches. In this case one potential target group would be the job seekers, and on the other side the employer. Now you already have two potential personas.
Give them names: The job seeker is called Joe, the employer’s name is Robert. Now give them some characteristics: Joe is 24 years old, recently finished his architecture career and is eagerly looking for an internship. Robert on the other side is 36 years old, owns a gardening business and is looking for new employees that have 10 years experience in the sector.
Based on this you already have a very good picture of two interest groups that might be using your software. Now you can go ahead and confront those “imaginary" characters with your product. Try to do what they would be doing in their particular cases. I promise you will find a bunch of interesting issues that you were not aware of while planning your project.
The paper & pencil phase
What follows is usually the part of the project where you start to scribble, sketch, fantasize, test, create, discard, and just let your creativity flow.
While you should enjoy this process as much as possible because you are still allowed to do mistakes, it should also lead to some sound results that the rest of the development cycle can be based on.
The following may guide you in the right direction:
Specifying beforehand
If you have the time and resources, put together a collection of scribbles for each screen of your future application.
Based on these, you can define each screen’s user interface components and which functionality they represent as well as the states they can be in.
This document should exist before you actually start implementing anything. This may sound stupid and overly cautious but I have seen it happen that people develop something that they think needs to be there but has never been asked for.
Like this, you can be sure that all team members have seen and – more importantly – agreed upon what is going to be accomplished, preventing misunderstandings at a very early stage.
Quick prototyping
Consequently, the next step would be to outline the application’s interface and test some of the basic functionality with the help of rough user interface designs.
At this stage, you’ll want to show how things are looking on the screen, without going into too much detail, something which would be perfectly in line with the concept of Prototyping in the browser.
Instead of working on pixel-perfect Photoshop layouts which are usually not congruent with the end results, start shifting your mockups directly to where they are actually going to live and breathe. Maybe you even want to go down a different route and try to design your user interface with the help of style tiles.
This allows you to directly expose your design to each of the target devices and start testing right away.
Planning flexibly
While there is nothing worse than a project plan that you define once at the beginning of the project and never change, many people in business are still thinking that you can “anticipate" every possible problem and circumstance in the analysis phase of your project.
From my experience, it makes more sense to set up a rough application infrastructure and timeline at the beginning instead and let it evolve over time. That’s also one of the best advices I have been given once by one of my computer science professors at university: To let your Gantt charts, UML diagrams, and application infrastructure breathe, develop and emerge over time.
This allows you to stay flexible and react properly when new challenges occur. With every new issue you face, like a deliverable that is delayed or a technical problem that requires extra resources, go back to your initial plan, revise it, swap priorities, and in the worst case, start it all over again, but this time with the new insights that you have gained.
Agile implementation methods
The approach of rapid development cycles has become very popular during the last couple of years. Agile due to Wikipedia means “software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration".
Let me pick three of its popular methods and describe them briefly as I think you can easily apply them without having to study the topic in its entirety.
Working iteratively
This ties in with the rapid prototyping method. Once you have shifted your layouts to the browser, get ready to incrementally fine-tune.
Iteration helps you to break up your big, seemingly monolithic project into smaller, more managable units. These units are small enough to be accomplished during day or week-long sprints, so that you can regularly present a new functionality to your project team.
These units can be split up among groups so that each of them can work on new features in parallel. With the support of unit tests, each feature can be tested and approved as an encapsulated module and then be integrated into the whole, something that is commonly achieved with continuous integration.
Delivering daily
This may sound odd, but it makes perfect sense to deliver new results on a daily basis, even though they may be small, seemingly insignificant improvements.
Not only does this approach contribute to the project team’s motivation and trust, but it also prevents you from hiding in your work and working on a new, heavy feature that eventually turns out to be useless or not in line with the requirements.
A project team usually appreciates it when you deliver regular, small results over time instead of promising a big release every week and not keeping up with expectations.
It also allows everyone to be part of the decision taking and get a deeper understanding of possible complications. The more transparent you are with your team, the better your relationship with it is going to be.
Don’t launch
This probably only works if you are not in some kind of client relationship, but are developing a startup project or are part of a team of like-minded fellows.
In order to not set the expectation bar incredibly high and avoid putting enormous stress on the development team (which in return can’t deliver good quality) just settle on releasing an acceptable version of your product as soon as you feel comfortable with it.
By agreeing on releasing something that is not perfect, you can already collect important user feedback that will help collect valuable user feedback and maybe prevent you from some decisions that you would have otherwise taken, such as a elaborating on a feature that turns out to be useless.
The inspiration for this idea came from the blogpost "[Startup Lessons Learned](http://www.startuplessonslearned.com/2009/03/dont-launch.html "Link to the blog post "Startup Lessons Learned"")" by Eric Ries.
Conclusion
I’m sure that you are already familiar with one or the other method I have mentioned. That’s great! It’s also important that we remind ourselves every now and then of the concepts and best practices people have invented throughout the history of computer science.
This summary is particularly meant as an inspiration to make use of the great possibilites we have at our disposal. Often times, we dive quickly into the design and development phase, since this is where things actually get created. I find it important however to also take a step back sometimes and look at the overall picture and if we are happy with the way we approach projects.
I hope you’ve enjoyed the article and I’m looking forward to your feedback, especially what kind of processes and methodologies you have established in order to deal with projects in the most effective way.