I’ve seen companies which try hard to grow¹. I often can’t see the point in getting more people to work for them. Investing in the current people pays much more, I think. If you take the span of bad people to very good people which can be ten times more productive², wouldn’t it be worth to invest five times more money and time into these people than hiring more and more? Every single person increases the communication effort and slows the whole organization down. Whereas a slim, highly productive team increases the quality and lowers communication effort.

More productive?

There are many factors which influence the productivity of people in software development.

• Speed (Function Points per Week)
• Defect rate (bugs per Function Point)
• Communication effort (knows how to use Google and Books)
• Cost (Cost per Function Point)
• many many more…

Lets compare two groups of developers, one slightly better than the other⁵.

Developer	FPs/Week	Bugs/Fp	Euro/Week	Euro/FP	Additional communication-effort
A	100	0.01	1200	12	0.05
B	66	0.02	800	12	0.10

So, developer A is clearly more productive than developer B, but costs more.

Imagine a project with 1,000 Function Points. It has to be code complete in five weeks.

Group of A-Developers

1,000 Function Points in five weeks are 200 Function Points per week. Our team has to consist of three A-developers. Ideally, three developers produce 300 Function Points, but we have to consider the communication effort: (3×100) x (0.95³) = max. 257 Function Points. Cost: 18,000 Euro with a combined defect rate of 0.0297³.

Group of B-Developers

This group has to consist of six developers. (6×66) x (0.9⁶) = max 210 Function Points. Cost: 24,000 Euro with a combined defect rate of 0.114.

Summary

As you can see, a few developers which are slightly better than another group can easily outperform a double sized team:

Team	Number of developers	max. FPs	Cost	Defect rate	Communication effort
A	3	257	18,000	0.0297	0.1426
B	6	210	24,000	0.114	0.4686

You could easily pay the A-Developers the double amount of the B-Developers and you would still produce a better⁴ product in the same time with the same expenses! Additionally the A-team still has more capacity left for changing requirements or unforeseen problems.

Again, wouldn’t it be far better to support and develop your current staff than simply adding more people?

¹ In terms of “hiring people”.

² The numbers came from two different sources. The first one is senior Siemens manager, and the second one is Paul Graham.

³ One minus the probability of no error: 1 – 0.99³

⁴ More features or superior usability and less defects.

⁵ Never trust a statistic you didn’t fake yourself.

—
Adding manpower to a late software project makes it later. —Fred Brooks

Whereas I don’t have the experience to write about it, I’d like to show some lecture notes and summaries about leading in high-tech.

Science, technology and tools often hide the most important fact: your people are your capital! The better your people the better your products. Of course you can hire highly trained people, but it’s your obligation to give them space and opportunity to evolve.

Your employees are highly motivated and highly trained after their schooling, but all to often the get demotivated far too fast. Why? One thing I’ve blogged about earlier is to tell them how to do their task instead the goal. This leads to an interest conflict, the requirements may conflict with the employees liability. Simply put: I can’t be responsible for things I was forced to do.

Software Engineering is somehow special in some cases:

• Ideas are the driving force
• The outcome is often unsure
• Research leads to knowledge gain; Development to products; these two often get mixed up and lead to nowhere
• Progress is hard to measure (90% syndrome)
• Unsafe starting-point (changing requirements; incomplete foundation)
• High complexity of modern software products

To support the worker, you must make sure

• to give them enough freedom to think
• to enable quiet and uninterrupted working
• to enable communication between the people
• to supply the needed tools
• not to condemn errors – these are necessary within a creative environment

Important points to keep:

• bad ideas lead to bad products (often the first idea won’t be the best)
• the best idea won’t lead to success if the routine work fails
• methods enable creative thinking (they free you from thinking about routine tasks)
• processes make projects faster! If a process slows you down (long-term), it’s the wrong one.
• your people want to be proud of their work, make sure they can.

—
Managers are hired to amplify the productivity of all people around them. —Scott Berkun; The Art of Project Management

I don’t like first ideas. Most people working with me may have painfully experienced that¹.

I really think that idea generation is vital in our business. We can’t afford (anymore) to take the first idea and start working. Knowing the alternatives is much too important. All too often I see people thinking of a problem and the first idea that seems to make sense is it. These (non)efforts result in changing directions in the middle of the development, or in starting over. Both very expensive experiences.

Sometimes the fist glance (see Blink²) is very important and a very powerful tool. But in this case, with systems more complex than most other products in the world, that won’t work.

I really enjoyed Scott Berkuns “The Art of Project Management³”. Especially because he dedicated some pages on that problem. When we start to think about a problem we should explore the problem space as far as possible⁴. Know what’s allowed to do and think of as much possible solution within these boundaries as possible. At some point the solution space stops expanding and collapses. This is partly because some solutions are not feasible, and partly because the solutions overlap. At the end you should have a few very distinct solution-proposals. Now it’s time to analyze those. Do they really solve your problem? Is this what the users want? Is it feasible? How much does it cost?

At the end of this process you should have one solution which is very likely significantly different from the first idea. And you have a high chance that you’ve chosen one of the best solutions possible.

Bad ideas simply lead to bad products, but also good ideas lead to bad products if the rest fails. Nevertheless, many of the failing projects⁴ have problems with their foundation (requirements and ideas) than with the implementation (design and code). Unfortunately changing the foundation gets very expensive the further the project develops.

¹ On the other hand, my blog-articles are rarely more than a blink of an early idea.

² Blink by Malcolm Gladwell

³ The Art of Project Management by Scott Berkun

⁴ You have to know when to stop.

⁵ Number vary, but standish offered these: 31% are cancelled before completion, and 22% slip their schedules. Most of them had problems with their foundations.

—
I don’t stop searching for a needle in the haystack, even if I’ve already found one. —?

The scientists of today think deeply instead of clearly. One must be sane to think clearly, but one can think deeply and be quite insane. —Nikola Tesla

Wow, that’s a great book! I own over 80 non-fiction books but only few of them excite me that much. The Pragmatic Programmer from journeyman to master from Andrew Hunt and David Thomas is one of those. It’s stuffed full with practical wisdom and tips you can start using from the moment you read it.

They discuss all relevant topics of programming and software development, starting from text editors, IDEs, code generation, command line versus GUI etc… to estimation, handling requirements and documentation. It’s fantastic and really fun to read, too sad it has only 300 pages.

Usually the quotes on the back-flap of any book should be handled with care, but Ward Cunninghams quote If I’m putting together a project, it’s the authors of this book that I want. ... And failing that I’d settle for people who’ve read their book. doesn’t really surprise me after reading just a few chapters.

(The second one equally full of wisdom, but with another focus, is Robert C. Martins Agile Software Development. Principles, Patterns, and Practices. Before buying several books on Design Patterns, Agile Methodologies and Software Development guidelines buy this one.)

Even if these books are from programmers for programmers, they’re extremely well written (meaning they don’t use nested parentheses (like me))!

—
An investment in knowledge always pays the best interest. —Benjamin Franklin

I’m always impressed if someone codes like it’s all he or she has ever done, without IDE and still n-times faster than anyone with an IDE.

During the past few years I’ve done a lot of Java coding. I’ve used Eclipse most of the time, but until now I didn’t realize how little I really know about Java¹—my skills largely depended on my IDE of choice.

Most of the time I don’t have a clue where (in which package) a specific class lies, as well as I don’t know (even roughly) what exceptions are thrown. For these tasks I asked my IDE to generate the code I needed (import, try/catch or throws statements).

The last few days I used ANTLR to generate a parser. I didn’t use an IDE (there is none for ANTLR 2 available for free), which meant I had to refer to the Java API to check whether my imports are right, how this or that method is named exactly and which arguments it’ll take (what Eclipse has done so far. It is to be blamed that I only know approximately the first three characters of a method name²).

If we are coding for productivity, in our day job or where time matters more than sharpening our skills, it’s fine (and sometimes crucial) to use an IDE. But if we want to learn something and get better (smarter) at our tasks it actually does harm: we’ll end up thinking man that’s easy I must know pretty much everything about this or that⁵... where in fact we only know how to use our IDE and don’t know s##t about the language itself³.

Another dangerous thing with code generators is, that it seems pretty easy to get up and running with a mid-sized application. We write a bit, generate a lot and we’re ready to go, isn’t that so? No, only at the beginning! If we (or someone else) need to change something in that code, maybe weeks or months later we have to understand every bit of the generated code (Ben has written about that too), now we’re screwed. If the code looks messy why should anyone bother to do his/her best to make clean changes?

If it’s easy to copy and generate lots of code why should one bother and think about abstraction, generalization and stuff? If I had to write getters and setters by hand, I would do anything to avoid it. Maybe (just maybe…) I’d just start designing my programs, making a real O-O design (or write a generator to write them for me, but that’s another story).

The previous problem can easily be avoided by hiding the generating the code. In Lisp one writes macros to generate code at compile time, xDoclet generates code as it’s own step, EJB 3 generates code at compile time too.

Now, what’s the point? Use a plain text-editor⁴ for educational purposes and avoid generating too much code with your IDE on your day job.

¹ Java in terms of packages structure, method names etc. Meta-concepts like algorithms, techniques, patterns etc. are out of question.

² That’s a great example for a quote out of Donald Normans book The Design of Everyday Things Knowledge in the head, and in the world: Precise behavior can emerge from imprecise knowledge, and, of course his Things that make us Smart book. None of these things make us an expert… merely an user.

³ You can be a pretty smart programmer, but don’t know a lot about the used programming language. To be a true expert you have to dive into the language itself and don’t rely on an IDE.

⁴ There are many high quality editors out there. I like TextMate most, but Emacs, Vim and JEdit are quite good too (and free, but keep the learning curve in mind).

⁵ See Unskilled and Unaware of it (PDF, 500kb). Somewhat related: Being a specialist (PDF, 164kb).

—
The Brain: Pinky, are you pondering what I’m pondering?
Pinky: I think so Brain, but if you replace the P with an O, my name would be Oinky, wouldn’t it?