Yeah I hate that point too. I think a better solution would be to sit down with a co-worker and talk it through, rather than having to ask some god-like "architect" who knows everything about a system.
I'm an 'architect'. According to my job title. I just program, man. It's not even complicated stuff. But bare competence is apparently beyond the pale for the majority of people.
Well, maybe. If you can put paint on a paintbrush and transfer it to a canvas, are you suddenly a "painter", or just a guy with Cadmium Yellow smeared on his shirt?
If you're talking about art, you'd have to ask Jackson Pollock about that ;)
I'm not bagging on 'architects', I just think the article pulls its punches when it says... "and for everything else, ask a grown-up". Well what if you ARE the grown-up?
In a sense, what the table is saying is: "don't commit to estimates longer than a few days". I think that is great advice if you can get away with it.
Understanding the problem and coming up with the detailed design is what usually takes time. The problem is that this information is expensive to produce. In fact it is usually the majority of the development effort.
Development tasks come in at varying levels of well-defined-ness:
* Imperative specification: Implementing a trivial, well specified feature, where all the edge cases have been specified. "Add a new field to form #37, store it in table 'blah', valid input is this regex...". Of course there is usually no problem with estimation in this case.
* Declarative specification: That is; the customer or stakeholder knows what they want, but you will have to do the design work. "We need I8N support in our webmail product. We need a dropdown in the compose window, and a language selector here and ...". Usually the edge cases in the specification are fuzzy and often it will turn out later that the customer didn't understand certain aspects of the problem themselves. Estimates will vary wildly depending on how much time is allowed to produce the estimate, and what approach towards a solution is envisaged initially. Most of the work is actually understanding the problem and producing a detailed design. It requires an intricate understanding of the existing code-base and the problem domain (in this case I18N). This how things really work in most of the industry. Not saying that's right though.
* Debugging: The pathological case. Fortunately, beyond triaging, most people don't expect estimates for this. When fixing really complex bugs (e.g. perf in a huge distributed system), sometimes the best you can do is produce a plan and demonstrate progress.
If the solution to difficult estimation problems was just "give it to an architect to decompose the problem" then estimation wouldn't be hard. This approach would work, if we assume the existence of some mythical architect who can instantly decompose any problem into day or two sized chunks. Unfortunately there is usually no mythical all knowing architect to whom the problem can be punted and the team and PM have to work it out. Of course, estimation has costs too...
Hey, and I know you're really busy right now, but could you get that to me by Friday? ;)
That's a tricky one. On the one hand I'd say just a guy with paint on his shirt, but the fact that you know what Cadmium Yellow is definitely qualifies you as a painter!
I'm sick of this whole dichotomy of "architects" vs "programmers". It makes it seem like the "architects" are the brains behind the system and the "programmers" are just code monkeys. I'd hate to work in an organization where that was the case. I expect even junior developers to try to have a holistic understanding of the system, even if they might need some guidance from more experienced folks.
