Man-hour isn't a fixed size entity

by Rasmus Hvidberg Josiassen 7. January 2012 15:54

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.

Tags: ,

Developer performance

What makes great developers?

by Rasmus Hvidberg Josiassen 28. December 2011 22:51

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

Tags: , ,

Developer performance | Software craftsmanship

About the author

I'm a software craftsman who ended up as manager and now is trying to get a grip on what makes good developers and how to establish a high performing developer environment in regards to people, processes and tools.

LinkedIn Profile


Month List