Agile Otter Blog

My friend and colleague Curtis Cooley recently blogged " You Might Have Too Many Developers ." Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups. You already know some developers are more effective than others.   What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000? Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers. The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers. I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.   As Red Adair would say : "If you think it's expensive to hire a professional ...

Eric Ries has suggestions on why/how to move your engineering practice forward and gain speed and reliability while you're at it: So how can I help the engineering manager in pain? Here's my diagnosis of his problem: He has some automated tests, but his team doesn't have a continuous integration server or practice TDD. Hence, the tests tend to go stale, or are themselves intermittent. No amount of fixing is making any difference, because the fixes aren't pinned in place by tests, so they get dwarfed by the new defects being introduced with new features. It's a treadmill situation - they have to run faster and faster just to stay at the level of quality/features they're at today. The team can't get permission from the business leaders to get "extra time" for fixing. This is because the are constantly telling them that features are done as soon as they can see them in the product. Because there are no tests for new features (or operational...

A common question on the TDD and XP mailing lists is how to get managers to approve refactoring and testing. The standard response is to ask in return why programmers need permission to write code that doesn't suck. The problem is that it is hard to know how to manage software development in a condition of rising Technical Debt . I was a programmer a long time before doing any management. I had to learn to manage my unit of work, to do things people wanted to have done, etc. There is a certain amount of professional discipline necessary to be a good employee-programmer. I had a tendency to do X (which was required) and throw in some Y and Z. Where Y and Z were simplifications along the path to doing X, it's all good. This shouldn't need permission (one would hope) but what about when they were solving miscellaneous potential problems on the side? What if they scratched an itch? Under the reign of SAS70 interpretations and ISO 900x dreams and basic risk management, I...