Hi alttag. Can you explain your comment in more detail? The intent of the article is not to say that delays are good or bad, but that they are inherent and inevitable, and must be managed as such. Maybe you have a different interpretation?
The biggest obstacle to me using TrollScript professionally is lack of testing tools. Troll-driven development is a fundamental tenet of XP which I'm not willing to forsake. Is anyone working on TSUnit or TSSpec? In addition, Cuke4Trolls would be a worthwhile project. I'd like to practice behaviour-driven trolling expressed in natural troll language, so TrollScript seems like the perfect target.
I think this is a case of premature optimisation. Trolls under Bridges is struggling to hit v1.0 due to the limited memory capacity of trolls, but someone is hard at work on a Node.js implementation of the interpreter. This will allow spawning a new worker process, or "troglodyte", for each request, and will be totally webscale (there will be no unnecessary trolling for events).
In addition, there's also a JVM port of TrollScript in the works, which will add a static type system to the language for troll-safety. This should alleviate any concerns that the language would be unmaintainable for large systems. JTrollScript will also have type inference to maintain the terseness of the original language.
Hi hammock, thanks for the comment (I'm the author). For some reason you've reminded me of the motivation factors Dan Pink talks about. I wonder if trying to commit to estimates makes our creativity degrade in the same way as paying cash bonuses?
Re "environmental contributions", that was part of the discussion, but thinking about it - estimating total effort and elapsed calendar time are very different!
Thanks for the replies both. Yes, this is one of the issues I have found: honesty over the risk in a project can make you look more expensive if you don't explain it carefully. This is especially true in a young relationship, when the client has not yet build up trust in the supplier.
Fortunately, I have found once clients are used to regular progress, they're more accepting of variation, and willing to accept estimates based on real statistics.
Thanks again for your comment, as you replied both here and on the blog, I'll repost my reply here:
John, thanks for your detailed reply. Sorry I could not respond sooner. I realise that my writing was imprecise in places, so I've edited the story very slightly to describe the situation better.
To clarify: the thatcher in the story did actually do some investigation upfront. I've changed the wording slightly to emphasise this. The problem in general, though, is how do you know when you've done enough risk assessment? The only way to eliminate _all_ risk is to actually do the project, but that is clearly way beyond the point of diminishing returns! But doing _no_ upfront inspection is flagrantly reckless.
Also to clarify: the thatcher did in fact work on a time and materials basis. However, I only vaguely alluded to it, and I've improved the wording again. It's interesting though that you assumed it was done fixed-cost-and-scope - I suspect that is the default situation people assume.
I'm interested by your suggestion of using professional indemnity insurance - how would the thatcher have used this? Can it be done in a win-win, none-confrontational way?
Finally, while I've included enough detail to describe a "full" project, the problem I wanted to emphasise was how (given both parties realise they are partially through a project of questionable value for either side) do they to resolve it in a mutually satisfactory way?
No matter how experienced the thatcher, or how carefully he manages the risk, there will always be a project lurking out there he had no way to prepare for. Improving at your job means being caught out by more difficult problems, as the easy ones you handle almost intuitively.
While you can get the benefit of clarity by stepping away from the keyboard for a while, I've found the best return is from test-driven development. TDD forces you to think about what you're trying to achieve before you try to solve the it. The thing I took exception to in the post was:
> 5. Make small change to the code on the off-chance that it might solve the problem
Whether practising TDD or trying to formalise the problem on paper (or in your head), this is not the way to write code. Programming is not a random search problem.
These days, I tend to only step away from the keyboard when I'm losing my bearings for where I am in the big picture. Usually, that's when I'm "making small changes to the code on the off-chance that it might solve the problem"… this means I don't really know what the problem is.
The thing I found by far the most interesting is about the sales process / incentives.
On the one hand, Apple is not encouraging dysfunctional competition within the team:
> We aren't paid on commission, but you fear for your job if you're not selling enough.
And yet on the other, they are:
> We have a posted list of our metrics, and you can see everybody else's. It shows you how much money each person is pulling in for the company. If you aren't doing very well, you start getting manager meetings, and they sit you down and try to figure out why you aren't selling more.
The best explanation of this I've seen is in the work of W. Edwards Deming. His Red Bead experiment demonstrates that in any system, there will be variation that is due to the system itself, and not due to the individual efforts of the staff themselves. Because of this, league tables and metrics randomly and arbitrarily punish people for performance variation that is out of their control.
On that basis, I find it strangely contradictory that a company with such ongoing quality efforts as Apple has produced a sales process absent of the disease of sales commission, yet still suffering the disease of Evaluation by Performance.
It's possible, however, that Apple is being more sophisticated than the post author realises. If they have statistical control charts, for example, there may well be no contradiction here at all (they would only be reviewing exceptional outliers). But with Apple's tight-lipped nature, I don't know if the evidence to decide that is out there yet.