Recovered from the Wayback Machine.
My response to a recent post in Google+ by Ian Hickson:
You’re comparing apples to oranges, +Ian Hickson. There’s a world of difference between developing a specific piece of software and creating a specification.
In addition, you’re also incorrect with your understanding of the ‘tech lead model’. You may have worked on a lot of specs, but I’ve worked on a lot of projects for a great number of companies. What you’re saying is, well, hogwash.
Typically, software applications are defined for one specific use: a business use with well defined and finite customers who provide detailed instructions (user requirements) about what they want.
The tech team meets regularly with the users, and the users—or the group of people representing the users—are the ones that have the final say on the product.
There is usually an overall architect if the project is large—but they don’t just think up what’s needed on their own, and attempt to tell the users what they want. And the architect doesn’t work in a vacuum. The data people are the ones responsible for data design, and others are responsible for other decisions, such as types of equipment to purchase and software to use. Then there’s the testing team, the user acceptance folks, the documentation people, and so on.
I’ve worked on a couple of systems, including support for Saudi Arabia’s air force defense system, where the numbers of people in the team number into the hundreds. Someone playing King of the Mountain wouldn’t last a day.
It is very much a team effort.
And many of these teams work really well. I’ve been privileged to work with great teams at Boeing, Nike, Sierra Geophysics (a Halliburton subsidiary), John Hancock, and various other companies and government organizations. One key thing about all of the teams is the understanding of the importance of each team member, that no one is King of the Mountain, and cooperation and mutual respect is the name of the game.
The problem with your comment Ian, and others of like nature, is you really don’t have much exposure in the real world. You really haven’t worked that many jobs for many companies. You’ve insulated yourself in a tech bubble and you seem to believe if you say something with enough surety and confidence, others will believe you. True, some do, but primarily only among others like yourself, who typically haven’t a significant exposure to real world development.
You’re all spec wonks.
Being a spec wonk isn’t a bad thing, and brings its own expertise to the table—but it definitely doesn’t somehow magically make you all capable of understanding what everyone needs.
Because you’re all spec wonks, it’s especially important to get feedback and input from others who do have the real world experience you lack. But you just don’t see that. If anything, you seem to hold real world experience against people.
“Oh, I’ve done more spec work than any of these people. What do they know about specs?”
They may not know the mechanics of how a spec is worded, they may not have a lot of experience building browsers, but they definitely know what works outside the offices of Mozilla, Google, Opera, Microsoft, and Apple.
You know what’s funny, but in the teams I worked with, the most important player was the end user. We used to complain—loudly—if we couldn’t get access to reps from the business end. We needed these people because they knew what the application needed to do in order to be successful. We wanted to create successful applications.
The browser companies, they’ve forgotten all of this. They cater to a small portion of end users—most decidedly geek—and have ignored anyone else in their push to Be First with the latest gewgaw.
They incorporate stuff into browsers now that make them insecure and decrease their performance, but it’s all Cool and Stuff, and that’s OK for the tiny audience they only seem to care about. The only problem is, in the real world, we actually care more about security, reliability, performance, and accessibility than if the browser is all Cool and Stuff.
You have users wanting to be involved. You have experts from other fields asking, sometimes even begging, to be involved. You have other techs with vast experience—real world experience—wanting to be involved. Yet you throw it all away. And then you brag about it.
Sad
