Keep The Challenge

Different software engineers get motivated by doing different things. Some get motivated by fixing bugs, others like trying to break the code. Software engineers like me however, like to solve complex problems, coming up with algorithms and data structures to solve the problem the best way.

While it is easy to provide enough bugs or code to break, it is much harder to constantly provide new problems that are challenging enough. As a result I often start to feel bored at work after a couple of months, but there are ways to solve this and keep the challenge.

Continue reading

The Worst Estimation Of Proficiency: Years

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”.

Continue reading

Team Structures

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.

Continue reading

Planning Ahead

Ever since I started working for the new company I have been working on this type of warehouse management system, although we call it ‘material flow control’. Many things have changed since the initial design (which I wasn’t part of), the biggest one being going from a generic to a specific approach. At the moment this decision was made, my team lead also told me to forget about persistency for now and just focus on the functionality.

With all the bare functionalities implemented, it is time to start working on the presistency. This proved to be much harder simply because the design wasn’t made with persistency in mind. So my first priority was to refactor a lot of the code so it can be more easily be stored and recovered from a database. Clearly this could have been avoided and saved a week of effort for the already too tight deadline.

Continue reading

Speciality vs Generality

Creating software is no longer the small business where you could learn it all and be a full expert able to do everything yourself. The business has grown and has become mature, being an expert in every field has become impossible. This leads us to dilemma of either specializing in a subset, leaving you clueless about the rest, or should we generalize and learn a basic understanding of all of it. This will depend on what your responsibilities are, as the ICT offers a vast variety of jobs. In this blog I will talk about the advantages and disadvantages of both as a software developer.

Continue reading

Towards A More Agile Team

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.

Continue reading

Formalizing The Process

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.

Continue reading