I recently read a job advertisement, in which I stumbled upon the following phrase:

“You care about software, you have a passion for what you do which you can clearly convey by your actions rather than just waffly personal statements on your CV”

Well done!

Unfortunately such statements are rare in job-postings. And (as a result perhaps…) every job application and consultant-résumés I’ve ever seen are all about skills.

Don’t get me wrong – technical, business and communicational skills are of course a must. They just only cover part of the expectations I think a good software developer should meet.

A passionate developer cares about his craft. He takes pride in improving his skills (not just the technical stuff, but soft and business skills as well), in seeking new ways to increase effectiveness and productivity for himself and his team, and takes pride in delivering high quality products that meets the customer’s expectations. That’s important stuff!

Hence I would rather work with a developer with mediocre skills but with a keen interest and passion about his work and craft than a developer with great technical skills, but little or no passion for his profession.

I would expect a good developer to be able to provide thoughtful answers to questions like: “What do you think characterizes well-crafted software?”, “What makes code beautiful?”, and “Why are you software developer?”

I would also expect a good developer to spend at least some of his evenings on catching up on trends in the developer community, trying out new features in his development environment or reading literature on technical and soft skills.

And he’s not spending those late hours because he’s expected to, but due to a profound interest in his profession and career.

When a project-manager (and managers at large) takes a look at his project plan and realizes that deadlines are looming and the graphs on the burn-down aren’t burning at the right pace, he has three handles to pull. He can move the deadlines, he can lower the scope of the project or he can add more resources.

In most project-manager’s minds the implementation of a requirement equals a certain amount of developer-time. Thus the easy solution is to add more developer-time, and the requirements will be implemented equally faster. It’s quite simple, right? 20% more developer-hours shave off 20% of the calendar-time to implement the solution. Sorry, but unfortunately it’s not that simple.

There are three factors, which must be taken into account.

First: You can’t produce a child in just one month by adding eight extra women to the task. Some development tasks have the same type of constraint and require specialized knowledge and skills. Sharing that knowledge and skills can be difficult and expensive.

Second: When adding extra developers the need for coordination, processes, attention to quality standards and understanding of the requirements grows. And the people, who are most competent on training the new developers and reviewing their code, are often the developers who used to be the most productive ones. Hence adding new developers to the team comes at a greater price than just the hours it takes to train them and review their code, since the hours you spend on those tasks where the most productive hours you had.

I would suggest that when the project’s deadlines come under pressure, you should avoid the reflex action of adding extra man-hours to the project and instead be looking at how you can increase the productivity of the developers you already have. And if you decide to add more resources anyway (‘cause of course this in many cases is the right decision) then remember that a “man-hour” is indeed an entity that neither has a fixed size or a fixed price.

In my previous post on measuring developer performance, I claimed that we shouldn’t look for speed-coding hackers in our attempt to raise developer performance. Well it’s easy to state what we shouldn’t do – and much harder to tell what we should do… So here’s an attempt!

I believe that developer-skills fall into three major categories, which are equally important: technical skills, business skills and soft skills. The latter includes (if not primarily consists of) communication skills.

By technical skills I don’t think of detailed knowledge of frameworks or tools (which, I might add, is what most certifications measure) – that kind of stuff you can look up easily. I’m thinking of knowledge and experience with patterns, practices, code smells and design principles.

Business skills include detailed knowledge and interest in the business domain and the customer’s needs to a level where the developer is able to challenge the customer’s demands.

And finally soft skills include good communication skills and taking responsibility for the entire project’s success (in essence meeting the customer’s needs on time).

Well… I admit, although the above is a definition of craftsmanship, it’s still a bit fluffy… So let’s try to break it down into smaller pieces. Here are ten skills, I think covers it:

1. Be professionally curious and take responsibility for your own learning
Read literature on code, practices and craftsmanship. Attend conferences. Examine new trends and dive into topics of professional relevance within the tools, methods and development principles.
Take responsibility to develop one’s soft and technical skills.
Read and/or contribute to relevant blogs.
Try new features, tools, methods and development principles to improve your skills and to introduce new elements into your organization’s development environment.

2. Contribute to the development platform and develop the group's level of competence is constantly improved.
Share your knowledge of professional trends and new tools, principles and methods with your colleagues.
Participate in efforts to develop methods, skill level, development principles, etc.
Take independent initiative to introduce new methods and principles in his team (Eg TDD, CI and Continuous Delivery)
Contribute to the development of the architecture

3. Write good code
Write understandable, robust, tested code of a high quality
Be experienced in relevant languages and tools for your development platform
Implement practices on Clean Code, Continuous Integration, Test Driven Development, development principles, etc. in your team's daily work

4. Understand and use OO and patterns
Be experienced in the use of the most common patterns and be able to recognize them in the code.
Understand software paradigms (OO, functional, procedural) and have an understanding of fundamental OO (Eg Cohesion and cyclomatic Complexity)

5. Be experienced in estimation and estimation techniques
Have sufficient experience with software development and development methodology to provide thorough estimation where all tasks are taken into account.
Communicate assumptions, uncertainties and risks in your estimates clearly

6. Create trust and be constructive in your communication
Appear trustworthy and be constructive and appreciative.
Strive to be perceived by your colleagues and collaborators as a qualified and competent partner
Be loyal to your colleagues, manager and employer
Be engaged and constructive when new ideas are presented and demonstrates a high degree of readiness for change
Appear sturdy and resilient.
Help others improve their communication

7. Deliver!
Do what it takes to deliver the expected business value in the right quality on time
Get things done! Communicate any deviations concerning scope, quality or schedule in advance.
Take responsibility on the team's behalf for the overall delivery scope, quality and deadline is met.

8. Take responsibility
Take responsibility for the entire project’s success - not only for your own tasks
Understand the project’s goals and how your work contributes to these.

9. Understand business objectives and processes
Demonstrate a keen interest in understanding the business and their needs, so you are able to challenge the customer’s demands
Always think "why" before "how"
Find the right level of ambition in relation to quality and development speed.

10. Thrive and be motivated
Take responsibility for your own performance, job satisfaction and motivation

Some developers are more productive than others. And some developers are much more productive! Not just two or three times as productive, but much more productive! Some studies (for example Sackman, Hal, Erickson and Grant) claim that the factor is ten (and as a factor 28 in how fast the developers can write code). I don’t know if the factor is 10 or 28 – and I’m sure that it’s not about how fast you can write code, but I know, that the factor is big enough to make it worthwhile to dive into what makes great developers and how you can measure performance.

There have been many attempts in trying to simplify the task of measuring performance and finding great developers. Performance has for example been measured by the number of lines of code the developer produced, how many bugs he or she introduced into the code or how many function points the developer delivers per month.

But the number of code-lines does not say anything about the quality or the features delivered. You can write hundreds of lines of code a day, but if the code has poor quality and introduces a lot of bugs, is unreadable to the poor developer who has to maintain it and has bad performance it wasn’t very productive, was it? Then you’d rather have the ten lines of code, which just did the job right!

The number of bugs introduced isn’t a very good measurement either. Of course fewer bugs are better than a lot of bugs – but developers that code makes mistakes. A developer who does nothing makes no mistakes. And the developer can write fantastic code with no bugs – but if he or she didn’t understand the business and implemented the wrong solution, then it really doesn’t matter how many bugs the code had.

And finally Function Points (my favourite aversion) does not measure productivity. It measures features and does not take into account if the code is readable, bug-free, or implements the architecture. For example you would get a lower function point per man month score if you’d actually implemented a SOA or did a reasonable amount of layering in your code than if you just called the database from the GUI.

If one combines these measurements - and add others like the amount of documentation, compliance to standards and guidelines and so forth – you might end up with a measurement that made a little sense. But it still wouldn’t tell you anything about how well the business needs where met, how easy the software was to maintain or to which extend it implemented the right architecture.

I fully understand the need for measuring how well the individual developer is performing. How else can the organization hire and develop the right people? But since you get what you measure, introducing oversimplified measurements of performance does more harm than good to the productivity of the developers.

So if you need to understand the performance of the individual developer (and you do need that if you want to increase the productivity!), then look at his or hers code and see how well structured, readable, maintainable and architecture-compliant it is. Go sit with the developer and do some pair-programming, listen to the developer’s communication with fellow-developers, business-people and testers. Discuss best practices in processes, tools and principles. In essence: Understand how well the developer is performing instead of implementing simple measurements.

Software development is a craft. And you have to rely on the craftsmanship of great developers to get great performance. Introducing simple measurements of developer performance is a poor substitute for real understanding of this craft and what makes great craftsmen. So… go introduce that understanding in your organization instead.