Marek Blotny's Blog

Developer’s point of view

If you ask developers how detailed the requirements should be, they will tell you that they want to know exactly what clients want to get. And this is good! Vague, high level, general requirements are not going to work for them. Everything has to be measurable so that developers and testers can easily, objectively, assess if a requirement has been fulfilled or not. To give you an example, if client wants to get a clickable button with an image and a label then, in ideal situation, developers would like to get acceptance criteria like:

• size of the image is 16×16 pixels, supported formats: JPG, GIF and PNG
• font size is 12 px and custom styling is not in scope
• label is mandatory and can have between 1 to 20 characters, only alphanumeric characters are allowed
• and so on …

To summarise it – expectation is to get technical details for each and every element.

Client’s point of view

Clients are usually much more high level, they operate on business level. It’s quite rare to hear from a client that they want a “clickable button with an image and a label”. They don’t operate on this level of details, not to mention the size of fonts or number of characters which can be entered as a label.

Much more frequently you will get strategic decisions like:

• IE6 is not a supported browser but still site in IE6 should be functional
• All component should be mobile ready – components should use all capabilities of mobile device and gracefully degrade from smart phones, touch phones to basic phones
• Site should be functional for people who have Java Script turned off
• and so on …

These are all sensible decisions but of course are too general to convert them into acceptance criteria just like that. The devil is in the details…

How to bring these two worlds together?

It’s obvious that there is a huge gap, details-wise, between decisions made by business and development team expectations. Primarily it’s a business analyst, project manager and technical lead job to minimize this gap and get both sides to understand each other. But is it only up to them to do the magic trick? I don’t think so …

To find the common ground, both sides have to step out of their comfort zone. Developers have to start thinking not only how to build a solution but also how to set constraints which will reduce complexity and effort to the minimum and in the same time maximize value for the business. It’s definitely not an easy thing to do. It requires good understanding of client’s needs, deep technical knowledge and experience to assess what solution will work and what will cause more trouble than benefit in future.

Business also have to be involved. Making a few general decisions is not enough for successful project delivery. Business have to collaborate with development team and help them transform requirements into solution.

It’s all about asking right questions

Development team which wants to get more detailed requirements can ask:

1. So you want this clickable button with an image … what formats should we support?
2. And how many characters you will need for a label?
3. How this button should be rendered, are 12 pixels for a label the right size?

Or situation can be like this:

Dear client, we have prepared an example of clickable button for you. We think that in this version everything looks good and all the functional requirements are fulfilled.

1. Do you think that image size is correct?
2. We think that supporting the most common formats like JPG, GIF and PNG is enough. Do you agree?
3. We have limited the length of the label to 20 characters to make sure that button will look good and consistent in all cases. What do you think about that? Is that a sensible limitation? If you want, we can extend this limitation but it will require additional 2 days of work because of something …  Do you think that 2 days are worth it?

I think you can see my point here. First set of question is easy but all the thinking is on client’s side. Second set of questions requires preparation and is much harder, especially in more complex cases.  I think second case is the way to show that we, as a development team, are adding some value. We are not just sitting and waiting for all the answers to magically appear, we are actively looking for those answers, we are providing technical expertise and this way we are helping our clients to make educated decisions.

What is the final goal?

Projects always have a limited budget (and requirements which are exceeding that budget). Final goal is to maximize return on investment for our clients. Not by working extra hours or running over budget but by

• figuring out which requirements have the most value and focusing on them
• helping to transform general decisions into a solution by providing recommendations and technical consultancy
• keeping things simple, low effort increases customer loyalty
• steering clients out of bells and whistles which are costly

PM can be a bridge between a client and development team but usually PM on his own don’t have enough technical experience to generate recommendations and provide technical consultancy. It’s an objective for entire team.

What are your thoughts on that?

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.

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.