In my four year carreer, I recently started my third job. This may make me come over like someone who very quicky changes jobs but I never changed job for the money or some other better deal I would get at the new location. I have always decided to leave based on the work I was doing at that time, altough I must admit that in no circumstance I have ever changed to a job that was offering me less then what I had. My quick passage at jobs may sound like switching could have been the wrong choice and that the previous job wasn’t that bad after all, this is what I will elaberate on during this blog post.
At my previous job they were starting up a new project on which many different people from different locations would contribute to. To give you an idea of how distributed the team would be, it would consist of 7 people in 4 different locations. Altough we have come a long way, and communicating with people all over the world has become possible without much effort there still are some problems that could arrise.
Software has a very unique characteristic, you create it once but can deploy it as much as you like. This goes beyond the limitation of other industries such as architecture, manufacturing, etc. In those industries you design it once, after which you can mass produce it, but the production itself has to happen every single time. Software is not bound to this as it does not deal with any physical objects. This makes software a good fit for a product approach, were it not that people have different preferences and like some customisation.
The product we create is a combination of hardware and software, and recently we have introduced the policy of doing a factory acceptance test (FAT) for every vehicle (AGV) that leaves our company. The FAT is meant to make sure that every vehicle that leaves the company works correctly, at least that is the theory because in practice we still have a lot of problems with getting everything working on the customer’s site. The goal of this blog post is to go into depth about the reasons for doing a FAT, the pros and cons and why it is failing for us.
For companies it is hard to have a promotion path for software engineers. Some companies may have the option to promote to a leading role such as a team lead or a software architect. This promotion however contains a complete different role for the software engineer as he will no longer do any of the actual programming anymore. For some software engineers, among which I count myself at the moment, this is not desired, as it is the passion of the actual writing the software that drives us. This however means that some people will always be ‘stuck’ in the same role at the same level.
From this a different type of promotion path was created: the path of expertise. A software engineer with a lot of experience could use that experience and become an expert in some domain, giving him more responsibility for that part and decisions that have to be made. This is often indicated with the levels: “junior”, “medior” and “senior”.
Every company nowadays needs some software to operate, ranging from a public website to an internal shared drive to some 3rd party software for managing finances and customers. Typically this software would run at a server inside of the company but with the rise of cloud software more and more companies allow you to run their software on their servers instead of having to run it yourself.
This is nothing new as most often companies already out-sourced the management of the website to a hosting company that takes care of security, maintenance and availability. Now it is possible to do this for other software as well, but should you? In this blog post I will discuss the advantages, disadvantages and some remarks that must be taken into account when thinking about switching to the cloud.
As a software engineer you often don’t have much impact on the team structure and you just have to deal with what management decides is best. Management however often does not know the impact of team structures on the produced software. Splitting up people in teams will make this separation clear in the code as well simply due to the extra barrier communicating with other teams and code being developed in parallel without much knowledge of each other.
A number of factors that in my opinion affects productivity, quality and performance of your team are:
* Amount of teams
* Number of people in a team
* Skills of the people in the team
* Structure of a team
In this blog I will go over each of these topics and discuss them shortly.
It had been a long time since I really felt I was working on a big challenge, something I could really put my teeth into. This is caused by the nature of most of the issues I was working on, as they were merely small bugs. Besides that I also felt a couple of other problems within the company. Many of those I have already discussed in earlier blog posts. It is a combination of these that I felt the need to search for a new challenge and a new environment.
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.
I have been working for Inventive Designers for about 11 months now, and I’ve already gone through two internal re-organizations. Not the kind of ‘re-structuring’ that involves people getting fired, but the kind where teams are re-organized to optimize the working of the company.
It is important to note that our technical department is divided into two parts, being “Development” that works on the product and “Serviced” that works on implementing the product at customers, and doing small customer modifications. At the time I started working there were three different development teams:
- “Core Infra”: responsible for our own infrastructure and the infrastructure backend of our program.
- “End User”: responsible for the rest of the program.
- “Communication Center”: responsible for an extension to the program.
Though it could be argued that “Communication Center” was not a full team in it’s own right, as it existed of consultants who also had to work on customer projects. This made the team very fluid, and spread over many different things that were not involved with the actual responsibility.
Changes in team structure are common at Inventive Designers, as I was told that not long before I started working there, they changed the teams as well to come up with the structure mentioned above. But I will focus on the changes that occurred since I started working there, their purpose and effect.
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.