Archive

Tag Archives: organisations

Who owns the codebase?

04/07/2012
Agile, Development, Lean, Management
2 Comments

Ive been involved in quite a few discussions about shared code lately, mostly because I’ve been working in a team that has developed a set of internal tools that are going to be used across the company. One of the common topics to debate in this area is what happens next?

After the main part of development has been done, who is responsible for mantaining and evolving this shared codebase?

I’ve written a little bit about shared code and I don’t think it is the best solution for most cases, but in a few situations sharing is necessary, so how should we handle it?

As any popular topic, opinions are diverse, but here are my two cents to the conversation:

It depends : )

The way I see it, there are two main types of shared codebases that can exist in a company, and each of them should be treated in a different way.

Components that are not critical for any team

This is the case of the famous “utils” package, or any other component that was once written because someone needed it and then was reused since it was useful for other people. The main characteristic here is that this code doesn’t sit on the critical path of any team/application. In other words, I could choose to use it or not if it fills my needs.

In this situation, I believe that using an open source model is just fine. Think about your packages as an open source library, that someone can use it or not if they want, and if at some point it needs to be maintained or evolved, the people using it can spend some time doing it.

It doesn’t matter that much if they break things or take the codebase in a direction no one expected, since people can always use older versions or just find a replacement for it.

Components that are critical to teams 

Now this is a more delicate situation. If teams depend on your component working all most of the time, I believe the open source model is not appropriate anymore.

As I mentioned before, developing internal applications should also use a customer-centric view, and that takes time and effort. As the number of users grow and diversify, it’s important to have people in your team that can steer the development in the right direction, thinking about the roadmap for the future and also development quality.

Being a critical component, the open source model makes it hard for anyone to own the responsibility to maintain the code, and hard decisions that will have to be made start to get postponed, while patches start happening more and more.

It doesn’t take long until everyone is attached to a codebase that no one really understands and is afraid to change. In other words, legacy is written.

In this situation, the biggest step is to realize you have a product to maintain, and that will cost, as it costs to maintain any product. There is the need for a focused team that can plan the future and guarantee that users are happy with what they are receiving, and avoiding the pain will just guarantee a greater amount of it in the future.

Developing internally ? You are not special

21/06/2012
Development, Management, software
1 Comment

In different opportunities IT organisations need to develop internal tools/code to be used for its developers. The reasons for it are a lot of times questionable, like in some cases of creating shared code, but there are moments when they are the right option. With the rise of continuous delivery, deployment automation tools is one of the examples where common tools can be useful for a company.

When that happens, internal teams are often assembled to deal with this problem, and create solutions to be used internally. Unfortunately, these teams seem to suffer from a “too much introspection problem”, and often forget lessons learned about product development when going on their mission.

There is a perception that because something is developed internally and “approved” by the head office (after all, they are putting money on it), other people will be much more receptive and understanding about problems and poor customer service.

Since there are no real paying customers and everyone will have to use the tool at the end (at least we hope for), the need for short product iteration and constant feedback doesn’t seem that necessary, plans are made to architect something that could solve all the problems, just not the one that the users are having.

The problem is that, in reality, market laws operate internally to a company as much as they do in the outside world, and poor over architected solutions that are forced upon users are still not a big hit, even between the organisation’s walls.

For real products (the ones that people pay for), the current solution are lean startup techniques and product teams, and I believe the frame of mind when entering the world of internal development should be the same.

Start with a vision, not a complete solution - Even when the problem is supposed to be known and understood, it usually isn’t as much as we hope. Over-architecting is a problem here as in any other software project and the only way to avoid the plan to fail when facing reality is to start small and validate your idea as you go along. Yes, Im talking about a MVP.

Get out of the building - In this case, your users are probably inside the same building, so there are really no reasons to avoid them. Walk around the floor, find the people that you will help with your product and get them to help defining what needs to be executed from your vision.

Iterate fast, close to the customer - Get your solution out there to be used from the beginning. Sit with your users, help them adopt it and treat feedback appropriately (as in hear it and do something about it).

Use metrics, track adoption and problems - Metrics are there to be used, so why not get them to help understanding how your tool is being used and adopted by your colleagues (or not)?

In summary, despite not having paying users, internal software is also supposed to help somehow, and if it doesn’t, it will be left behind and forgotten, so companies should give it the importance it deserves.

Duplication? Yes, please!

14/06/2012
Agile, Development, Lean, Management, software
2 Comments

A common topic when discussing IT in organisations is how to structure software teams, more specifically, how do we divide work when a company grows enough that one team is not enough anymore, and how do we deal we shared code?

This is not a simple question and probably deserves a few blog posts about it, but now I wanted to focus on one specific aspect of it, which is the duplication of effort.

A simple example would be if my company has multiple teams delivering software, they will eventually find the same problems, as in how to deploy code, how to do logging (the classic example!), monitoring and other things like that.

And in almost all organisations I have been, the response is unanimous: we should invest in building shared tools/capability to do that! It’s all in the name of uniformity and standardisation, which must be a good thing.

Well, as you might imagine at this point, I disagree.

Building shared applications in IT is the equivalent of economies of scale for software, and it is as outdated in IT as it is in other industries.

In knowledge work (as we all agree software development is at this point), no effort is really duplicated. You can develop the same thing 100 times and you are most likely getting 100 different results, some quite similar but yet different. And that small difference between each other is where innovation lies.

This is the trade off that companies should be aware of. If people don’t have freedom to experiment and look for different solutions for problems, is very easy to get to a place where everyone is stuck in the old way of thinking. And that’s what companies are really doing when making people use common tools, shared applications, etc.. They are putting cost-saving in front of innovation, a lot of times without realising it.

And I don’t mean we can’t all learn from each other and reuse solutions when they are appropriate. After all, there is still a place for economies of scale when appropriate.

We are all standing on the shoulders of people that came before us and should keep doing it, even internally to an organisation. But that should be an organic and evolutionary process, not one that is defined by an architecture team.

Follow

Get every new post delivered to your Inbox.

Join 835 other followers