Amen brother...

As a profession we seem to have forgotten a lot of skills that IT practitioners learned back in the day. The things you mention are the kinds of skills that other professions like engineers, architects and doctors have built up over generations. They comprise the transferable body of knowledge that makes those professions as powerful and effective as they are today.

It's about time for the IT profession to get serious about creating a coherent body of knowledge that can be tranfered to and added to by the next generation.

I'm not even sure to what degree the hardware implications of software engineering are discussed in education anymore. For web developers, most really do not have any formal training on the systems they are developing applications to run on. It's quite common these days for developers and IT to be silo'd. Only after an application gets rolled into production do the shortcomings of poor systems design come into play, and then we see developers and IT working together to fix the problem.

I think we have certainly grown accustomed to throwing hardware at the problem. It's hard not to as business requirements change throughout the development phase, forcing developers and engineers to change the scope of the project along the way. Deadlines are often favored over quality of work because you can always go back and fix the code later, when you have more time.

-Eric

I am with you. One of the problems is that technology and development move so fast that it is difficult to maintain a consistent transfer of knowledge from one generation of software developer/designer to another. With doctors, young internists learn from experience of seasoned MD's along with real world experience. With software, you don't have a bunch of web developers sitting down and absorbing the knowledge of a mainframe guy - in fact, most young developers view people on older systems as useless and have little to no respect for them. I once had a guy that graduated with a master's degree. First job, and I was the software designer. He looked at me as a dinosaur and argued EVERYTHING I said. Didn't matter that he was surfing to try and get ammo for his arguments. He never presented any correct or experienced info to support his argument.

Solid Software Enginerring practices should transfer to anything you are designing software wise and should be taught and practiced. But the dollar and the bottom line rule the day.

Very true, but on the projects I've dealt with, the kinds of requirements you mention belong in a non-functional requirements document (perf, scale, concurrent users, etc.) One problem I've seen frequently is that when technical info is included in the functional requirements, the writer tends to live in the database and does not have a holistic view of the system. So, you can end up with requirements that are very myopic and do not explain the business rationale at all. For example, I've seen reqs docs littered with items such as 'add X field to the database', but no explanation of why this is necessary, no reference to a conceptual business entity, no context whatsoever. Easy to fulfill technically, but at what longer-term cost?

I suppose all I'm saying is that I agree with the original post that both functional and technical requirements are necessary, but let's let the business people write the functional specs, the tech folks write the tech design and both collaborate on the non-functional to determine what's feasible given the constraints of the project.