Just like any other tool, a software application is always created with a purpose. This purpose can range from something funny or really cool to a potential live-saving First Aid application. However, good systems have something in common: they solve a specific problem or answer to a specific need of the end-user. Applications are sometimes created by a bunch of 'frustrated' developers that look for solutions to problems in order to 'improve the world'. Fair enough, most of the time it's when a client reaches out to a mobile agency like us to collaborate on a solution. In this case, the client introduces us to a problem which they want to solve, with a specific group of users and specific goals in mind. This marks the beginning of the development process, because an important part is to get to know this specific group of users and learn about their needs and expectations.
According to our way of working agile, we like to describe the development process as a development cycle: A loop of rapid iterations, learning and feedback, both from within the developing teams and the end users. Nothing is as changeable as the development process.
Two types of development cycles
When the team starts a project each team member starts forming so called hunches. These are ‘gut feelings’ based on his/her experience and their assumptions about the end-user. To form a shared understanding on how to best resolve the users needs, the team needs to validate these hunches and assumptions not only with each other, but also against these users. After a release, but often also during a development cycle, the developer learns about how the product is used and if assumptions made earlier were correct.
You can define development cycles on 2 different levels. The first level is where hunches from different team members collide into a shared idea. At first the idea seems awesome. However these ideas are during the initial stages of development mainly based on assumptions. To avoid group thinking, a second level of cycles is brought in. It's the actual verification process where the team acquires valuable feedback from the users to improve the idea.
Software development is all about creativity and Creativity is driven by the collision of hunches. The development process exceeds disciplines. And these disciplines all have their jargon. They basically ‘speak a different language’. In order to communicate, brainstorm and collide hunches smoothly, you will have to learn parts of the other disciplines. For example, a U.X. designer that designs a user interface for a website should be able to understand the web developer. The designer needs to be aware of how the user interacts with the website from a technical angle.
Also within disciplines, especially the development camp, there should be a common understanding. For example, Android apps need to communicate with a server in order to get data. This means that both a server-side developer and an Android developer need to know the protocol that allows these systems to communicate. We form multidisciplinary teams, placing them physically together, to get the most out of the development process.
Iterations and working agile
Iterating is a method to take a moment to acquire feedback about what you are doing while at the same time sharing your ideas with other developers. This can be a testing round with actual users, asking other developers or just reading on the internet about similar problems. Each iteration should be about asking the question "Am I going in the proper direction?".
If that answer is no, consider taking a different path. Iterations are part of the routine in modern software development. You check with the team how the week went, what you and your team should do or perhaps stop doing. The most common iterations are the weekly sprints. A smaller iteration is the daily stand-up where each developer tells the team what they did and what they are going to do. A team-up with members of your own discipline is also common to check each-others code. At the end of these iterations we have moments of retrospect. It's basically a check if everyone is still on one line.
These iterations serve two purposes. First, it's a learning process, and second, it's agility. Because each iteration is a checkpoint, it's also a chance to go into a different direction. The smaller the iterations the more chances you will have to switch direction, which will have little effect. If you write code, you can write the entire application without iterating. The downside is that when you afterwards conclude that a core component is wrong, you will have to rewrite the whole application. Instead, you can write a function, review it with the team and rewrite only that part if that's required.
Software development is all about iterating, learning and adapting. Developers often have their own assumptions in solving problems in a specific way. Validating the team assumptions with end users is an important part in the process.
The next development blog will be about naming conventions. Why is naming important in software development? How to avoid messy digital working environments? What about naming our functions in code?