457 karma · joined March 19, 2011
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.
My post is definitely not suitable for most management, but in a discussion with a bunch of fellow geeks, it did fit in with the discussion.
Explaining this to management/clients is not easy. It's a problem that needs tackling, but it's a separate problem.
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.
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.
> 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.
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.
Deming even listed "evaluation by performance" as one of the seven deadly diseases afflicting the western economy.
http://en.wikipedia.org/wiki/W._Edwards_Deming#Seven_Deadly_...
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.