[This entry was drafted in early January, at the beginning of the project for which we’ve now deployed Phase 1. Interesting to run across this now, as I’m wrestling with a similar problem of knowing when I know enough, now that I’m working on a prototype application using BEA’s portal product.]

My new project at work is a Microsoft .NET project, building an e-procurement system for one of our government agencies. Our schedule is very tight (see my Project wishlist that came out of dealing with the schedule) and the set of functionality to build is large. And the development team, including me, is very inexperienced in the technology – the team’s very senior, in terms of general development expertise, but has very little actual hands-on .NET experience.

Given a tight schedule and an inexperienced team, there’s a tendency to want to learn everything. Let’s see, we need in-depth knowledge of C#, of ASP.NET, of ADO.NET, of Win Forms, ………… What we don’t know can hurt us! And no senior developer wants to feel like they’ve just scratched the surface of a technology in which they’re required to develop a system. Where’s the balancing point, though? If we spend the time necessary to feel comfortable in .NET, we won’t get that time back in the development schedule. Sure, knowing more will let us develop faster and with fewer problems, but there’s definitely a problem of diminishing returns. Spending two weeks training won’t probably net me two weeks back in development time. [Follow-up note: nope, the training wasn’t worth it, given the time necessary for the class. But I at least have something to add to my resume. Most of the stuff we had to figure out on the project weren’t covered anywhere in the training.]

Seems there’s some fine line somewhere of just knowledgeable enough to do the task at hand, or, put another way, just barely above stupid. But there’s no Geiger counter of knowledge, or sniffing dog for stupidity. We, the very ones who don’t know enough, are required to figure out that inflection point of stupidity: that point where we’re just knowledgeable enough to make it over the hump to build something useful for the project at hand. Don’t go far enough in learning to hit the inflection point, and you’re not going to build anything useful. Go too far, and anything you build won’t be done in time. Gotta know when you’re doing stuff fast enough to figure out you’ve crested the hill, and then go full speed ahead doing, and put the brakes on the high-powered learning gear.