Marek Blotny's Blog

One thing which I see happening quite often on number of different projects is that developers have very limited access to the production servers. Actually in some cases they don’t have access at all. That causes number of problems, especially when there are integration points with other systems.

Of course as long as application is up and running lack of access is not a problem. But when something is wrong, developers are supposed to support the application and fix the ongoing problems. Usually in scenarios like this, when system on production is not fully functional, there is a lot of pressure to nail down the problem and fix it quickly. Developers without access are literally blind hence emails like ‘can we get remote desktop to production servers?’ between them, management and server admins are normal. If in the end developers will get a remote desktop access they can consider themself being lucky. Typically server admins and security policies are an impassable wall.

So what can development team do to put themselves in a better position?

Here are a few ideas:

1. There should be a diagnostics tool for each integration point. Especially if an application relay on 3rd party systems. Developers should have a way to check if 3rd party system is responding and if it’s responding in reasonable time. Another useful feature is to have ability to invoke calls on 3rd party system with some test data and verify if results are correct.
2. Each call to external systems should be logged and developers should have an option to generate a report with all the calls. It’s a great help when there is a need to investigate which system doesn’t work as expected. As long as developers can show evidence that for instance the applications asked 3rd party system to send x emails and only subset of them got delivered then it is clear where the problem is.
3. There should be a way to gather data regarding server’s performance. With time application most likely will be more and more popular which means increased load. Also amount of data stored within application will grow. It’s essential to monitor if servers are dealing with current level of traffic and data.
4. All unexpected errors should be logged and easily accessible. It again means that there should be an easy way to generate report with all unexpected errors. (like 500 error pages) I have seen a few times that information about unexpected errors were logged but they were buried somewhere deep in 1GB log files among other completely irrelevant information. In such cases developers can say that this information is logged but can they easily find it? Can they easily get all log files? Can they easily access all the servers?

Having access to all those data, developers can perform investigation and in reasonable time identify a few potential culprits. Moreover, on top of that layer they can build automatic monitoring system which can do most of the job for them and in case of unexpected errors for instance send emails to relevant people.

But to have all of that in place developers and also management have to realize that having diagnostics tools in place is not a strange requirement; it’s their duty as a professionals to foresee the problems and in future be able to tell what is going on with their application in any environment.

Conventionally role of developers in a project was fairly narrow. Project Manager was assigning tasks to developers; they were working on it and when done whole process was repeated for another task. Usually developers where left alone with their task, not bothered by the outer world.

Now, consider how different expectations are for developers in agile teams. Agile methodologies are tailored for cross-functional and self-organizing teams. That means a set of completely new responsibilities:

• Requirements are usually not very detailed so it’s up to a developer to refine them by asking questions and talking with business people.
• There is no PM who is assigning tasks, team should self-organize and take tasks which are available on their own.
• There is no PM who is estimating everything and committing on behalf of team. Developers are involved in estimation process and are asked to make a commitment.
• In cross-functional teams there are no specializations in some narrow aspects of software development or one specific technology. Everyone can pick up any task.
• Developers are not only responsible for coding … they are responsible for getting story/task done.
• Team should be able to reflect and adapt to the situation they are in. Finding the most effective techniques/processes is part of being agile.

That list can be much longer but I think you already see my point here. Developers in agile teams have to take much more responsibility on their shoulders. They are not only focused on coding, focus has been shifted towards communication, interactions with clients and other team members. Developers have to be now effective communicators. Understanding and using business terms is a must. Remaining with technical jargon is simply not an option.

Transition to agile developer can be shocking. Not everyone will be able to cope with this challenge. Some developers simply may lack interpersonal skills necessary for it. Others may not be keen to change their focus and attitude. So what’s the reward for the efforts?

I think agile methodologies give developers a chance to influence the development process, change it into more effective and this way improve quality of their own work. Their ideas matter, their actions can make a difference. Agile make developers empowered to change things and self-organize. I think many people will find such environment stimulating and motivating.

In one of my previous posts Are ex-developer good project managers I was exploring one of a few possible career paths for developers. Post was mostly about evolution from developer to project manager and how development background can help in new role. Under this post Pawel Brodinski left a thought-provoking comment:

I have one great idea for developers who want to transit to some other position: become a tester.

I didn’t consider this path as viable option mainly because it’s not a very popular trend. There was always an obvious gap between developers and testers. I do remember people talking that Microsoft “converts” poor developers into testers… I don’t know if this story holds the water but I’m sure stories like that bear in people’s minds. And it makes transition to tester less desirable, at least from developer point of view.

I believe that both professions require different mindset. Developers are accustomed to a joy of creation; their work requires creativity, and in the same time gives a lot of opportunities for instant gratification. If your new class or method work then great, you are done. It’s easily achievable and very positive.

On the other hand testers are not building anything, they have to verify that things built by developers work as expected. On a basic level this inevitably involves going through a checklists to make sure that (for instance) html renders correctly in all browsers. Repeating such steps over and over is not something that most developers would like to do.

But there are also similarities between both professions which gives ex-developers some benefits.  Advanced testers don’t have to go through checklists and check everything manually, in most cases it can be automated and this is the place where pure development skills are very handy. Another advantage is creativity which is a requisite not just for good developers but also for all good testers. Figuring out all possible scenarios in which given functionality can be used, checking all available paths; digging as deep as it’s possible – without creativity it’s hard for good outcome.

I agree with Pawel that good tester can be “well worth the bigger money than they coding colleagues”. Tester which is able to reliably verify that software works is invaluable. Testers who are familiar with typical development pitfalls are able to relatively easy find all edge cases; it makes them priceless members of any team.

What about instant gratification? This is essential thing which keeps developers happy. Do testers have something like this? I don’t think so … and this is what makes those two jobs so different and transition from one to another so hard.

I have been watching Cory Foy’s presentation yesterday. The presentation was about ‘Growing and Fostering Software Craftsmanship‘ but for me the most striking part was when Cory was talking about knowledge sharing and about Bus Number. Bus Number Wikipedia defines in a following way:

Bus Number is the number of developers on a project who could be removed before understanding of a particular part, or all of the codebase would suffer severely. The term refers to the fact that if these developers were unable to work on, or consult for, a project it would be difficult (or impossible) for new developers to pick up where they left off. In other words, if the developers were hit by the proverbial bus, the project would be in jeopardy.

So it’s pretty much clear that we want Bus Number to be as high as possible. We don’t want to see our projects to be so vulnerable. With low Bus Factor one unexpected event can lead to serious problems.

And here comes the most interesting part, Cory claims that in most organisations this factor equals exactly one! Think about it for a second … it means that entire project is in trouble with one person taking a new job, having a health problems or being hit by a bus. How bad is that?

Another point made by Cory – most organisations are not promoting knowledge sharing. Rewards and fame go to the people who know how to rescue projects, who are able to deal with complex projects, difficult clients. Knowledge sharing is not that high on the list, as a side-effect people don’t pay much attention to it.

I think usually people will agree that knowledge sharing is an important thing, but in the same time people tend to focus more on urgent things rather than important. As a consequence typical ways to share knowledge like code reviews, pair programming don’t happen very often.

What is the Bus Number in your organisation? How do you ensure knowledge sharing? Who should be the most interested in increasing Bus Number within a team? (PM? Tech Lead? or maybe someone else?)

Sooner or later developers have to start thinking about their career path. They are facing a question like ‘I have been programming for x year … now what?‘. As I see it there are three potential career paths for developers:

1. Well known path from development to project management
2. Purely technical path towards “senior developer” / “technical lead” / “software architect”
3. And finally third path towards technical consultancy

Quite often you can hear that developers are not good project managers. People say that mainly because being a good developer doesn’t make anyone a good leader or project manager. Programming and management require different set of skills.  Majority of developers got technical training and they lack soft skills which are essentials when it comes to managing people. However developers want to “progress” and in some companies this is the most natural way, the most obvious path. Transition to manager requires learning new competencies and changing “point of view” but for sure it’s possible.

Assuming that ex-developers feel good in the role of project manager  they have one big advantage over non-ex-developers PMs – they know what debugging is!

Every software developer knows how to debug code. When something goes wrong they can figure out what the problem is. Once the problem has been identified, they can figure out how to fix it. (In most cases.)

Ex-developers understand software creation process inside out. That puts them in much better position to investigate problems which may occur and solve underlaying issues. For them project is not only about tasks, estimates and tracking progress. They know what is really going on. PMs without technical background usually have following options when the project is in trouble:

• additional people to speed things up
• overtime hours
• functionality descope

Ex-developers are not limited to the above list, this is their strong side!

What does it take to advance from junior to senior developer? The most obvious answer is experience. But is it only that? Or maybe number of years of experience is completely irrelevant?

According to “What makes a programmer ‘senior’?” post, years of experience are not so vital, senior developer should have following qualities:

1. You know more than one (programming) language
2. You regularly code outside of work
3. You’ve built software from conception to implementation to support
4. You innovate
5. You apply software to solve real problems

I definitely agree that practical knowledge of more than one programming language gives broader perspective. I also agree that experience from each step of project life cycle is absolutely essential. Especially beneficial is spending a bit of time on support and learning on your own mistakes. That is supposed to be a time where you learn what is needed to design code in a way which is easily maintainable and open for extensions.

I can’t fully agree with the second point … not everyone has time to contribute to some open source projects, I can agree that this is nice to have quality but not essential. But is that all? Or maybe something else can be added to the list? Personally I would add two things:

1. Senior developer should have skills and knowledge on techniques and tools required to guarantee satisfactory application performance. This is not only ability to use load testing tools and profilers but it’s also about finding application bottlenecks, making sure that application scale properly etc.
2. Second thing is about right attitude – I expect from senior developer to be proactive, to be able to think about the work on a high level, to constantly strive for high quality solutions and at last to take a lot of professional pride in his work.

Each project, each experience should be an opportunity for each developer to learn something new and in that sense number of years of experience helps. But bottom line is … to advance to senior developer you can’t just focus on coding, you need to constantly develop your skills and seek ways to wider your experience.