What are the tiers of Development? Should they be ranked more highly than each other? A conversation Bill and I had today sparked my brain off.
When we look at Development, how do we approach it? There are a few levels, or tiers.
1. The Functionality
This is where the majority of coders lie, most probably. This is where most people start i guess. This is also the place that can bog down a lot of good Development.
"I’ve got this AWESOME idea for a piece of software/hardware!"
Like Joel on Software states I think it’s more important to build an environment where Development can be best fostered is better than coming up with a great idea and getting some people together to get it done. This (the second thing) has it’s importance, and does happen, but it probably comes best underneath the environment.
2. Support
"How do I support this Development to the Customer?"
Where the developer/development team start thinking about Support systems, help desk, ways to get feedback from the Users etc.
A very vital part of development. Once again, it comes best through having the environment in place. I guess too, that we should clarify this "environment" i keep bantering about. I’ll do that at the end.
3. How to Sell the System (the solution)
"How do I market/sell this piece of beautiful creation?"
This is where the rubber hits the road. You get this right, and BAM, a lot of the hurdle is gone. Client’s are there, the money is flowing. You get this wrong (like I have done), and -boing-, you’ve got nothing but a cool piece of solution that has a couple of users who will haunt you until you pass from this earth. Which is not ideal.
4. There is no spoon.
–==–
Environment:
This is where all the above tiers should come under. What we should have is a structure where we look at solving problems AND thinking up cool ideas. Not going overboard on anything. Balance our longing to dream up supa-software with looking at where we are as a team, what we have to get done, what problems are being faced right now.
A place (mostly where the people are, not a physical location) where we work smart (and hard, but smart first) and where we seek enjoyment. I love it when, after a couple of hours reading code, looking at the problem, it clicks. That’s a great thing, and it means that on a sub-conscious level i enjoy work. But also, I enjoy work because I know we can share ideas. We can push each other to think in different ways. Each of us comes at a problem with a different face. My talent lies in my inability to quickly grasp the obvious :) … so explaining to me has to be simple and straightforward, which in turn makes the explain-er think through what their talking about.
Anyway, this post is a mumble-jumble of ideas. But it’s on the right track i think.
‘Nuff Said.
p.s. Bill, if you read this, i think i mashed together the middle two points we talked about … can’t remember exactly :).
