Depending on what type of business you are active in, you either often start new projects from scratch, or not at all. In the first case you are more involved with proto-typing and experimental work whereas in the latter you are working on a product that needs to be supported, upgraded and maintained.
Starting code from scratch has a lot of benifits mostly caused by the freedom that comes with it. You are not bound to any choices made in the past, you are free to choose your own way of working that you are used to and feel comfortable with. There is also no legacy code that you need to understand and may be badly documented.
But what I want to address in this blog post is all the side-setup that is required when setting up a new project, and how important it is. Should it all be done from the start? Or can you delay it until it really becomes important?
At the company I work for, the software we develop is still mostly used on premises. In a world where cloud is the future, we are slowly making parts of our software available as a cloud service. This involves a huge shift in our way of working as we now become responsible for operations ourselves. We have only very limited experience with this as the we only had to maintain our own infrastructure, running the programs we use internally. Keeping our services available for our customers requires a complete different approach to keep the system up and running all the time.
Doing something new always brings forth the possibility of failing, since operations will become a critical part of the software we should do anything to minimize the chance of failure. The good thing is that we are entering this world pretty late, many other companies already provide cloud services and have gained experience in doing this. A hot topic of the past few years is DevOps, which is meant to increase efficiency of both development and operations, minimize conflicts and decrease time to market. Although it is still evolving and discussions (such as whether development should get access to the production environment) is still raging, DevOps is something that should not be ignored.
A challenge many software companies face these days is switching to an agile methodology. Agile has grown a lot since it’s initial start and it is now widely accepted as a good methodology to develop software, and in many cases even better than the original waterfall principle.
As can be expected many companies will want to change the way they work to take benefit of this. However, such a drastic change involves more than one might think. To get a clear view of this, I will discuss the original situation coming from a waterfall based way of working and what the ultimate goal is.
A waterfall approach usually involves many different people/teams, each with it’s own purpose and role, fulfilling one step in the model. Teams are managed by a team lead which fits best in the typical hierarchy of the company. Spending a lot of time in such an environment will create a narrow vision, where each person/team is only focused on their own part. On top of that a common phenomenon is that of “throwing stuff over the wall”, which means that as soon as you are done, you don’t really care about it anymore and it becomes someone else his problem.
How do we transform this to an agile approach where there is more involvement of all the stakeholders? The big difference between waterfall and agile is not that your team becomes responsible for everything, even when using an agile methodology everybody has their own responsibilities. The big difference is that everybody is committed, and a much more interaction between all the different parties is required.
As mentioned in the previous post, software development is a create process craving for freedom, but at the same time should the freedom be limited. In this post I will go a step further and look at why a developer should ‘restrict’ himself, take away a part of his freedom. This holds both if he is working alone, or in a team.
The kind of restriction I am talking about is formalizing the entire software development process. After all software development is still a process and to control and monitor a process we need to have a ‘path’ specified for the process. Only then can we find out what went wrong and where improvements are possible.
If you use an agile method, such as SCRUM, you will likely already have a clear process. This is resembled by all the stages an issue has to go through from being submitted until being resolved. This often includes steps as ‘In Development’, ‘In Review’ and ‘In Testing’, what happens at each of these phases can however vary a lot and it is important to define the responsibilities of each of them. By doing so you will be ‘formalizing’ the process.
The process of developing software involves a lot of creativity from the developer. Some would even say that the software that can be developed is only limited by the creativity of the developer. Whether you agree with this is not important, what you need to realize is that developers are often creative people (in their own way).
The more creativity a process requires, the harder it will object against any form of restrictions. The same goes for people, a very creative person will feel best when he can use his creativity to the fullest. An individual can never have complete freedom in a corporate environment:
- The company needs to be profitable
- A company involves many individuals that need to work together
- Pressure on the individuals to come with results
Software development at an enterprise level can not be done by one individual as the software to design and maintain simply gets too big for one person to realize something in a decent amount of time. To handle larger projects multiple persons are required, this raises the challenge of organizing them in such a way that they are as efficient as possible.
Though it would be possible to have every individual work on it’s own part of code, this is not encouraged for two big reasons:
- A bus factor of 1 is a huge risk for any enterprise.
- Designing software from one point of view will often result in something that is less usable for other people/purposes.
This means that people are organized in teams to work on some code together, having shared ownership and responsibility for the maintenance of the code. But as team size increases, so does the overhead of keeping everybody up-to-date with the latest state of the software.
Agile has been around for a while now, and most companies have realized that agile development is indeed better than the traditional waterfall model as it provides a couple of benefits:
- The product is closer to the needs of the customer as he is involved in every step along the way.
- Less bugs are introduced as continuous integration guards over this, leading to a more reliable product that cost less to maintain.
- There is no large up-front cost.
- Because the product is build incrementally, the chance the project fails to deliver something of value is much smaller.
Despite this, I experience every day how a company wants to be ‘agile’, but is stuck with the idea that being agile is only a development thing.