When we hear I'm a developer is that the same as I'm a Software Engineer. What does it mean to be a software engineering versus a developer of sofwtare? Peter Denning's review of he book A Whole New Engineer in the December edition of Communications of the ACM speaks to this question.
There are several important ideas here. One example in the review was from a 1980s in a study at the research institute at NASA-Ames Research Center where computer scientists were brought together with NASA scientists on big problems in space and aeronautics. Our scientists pioneered in applying supercomputers instead of wind tunnels to the design of full aircraft, conducting science operations from great distances over a network, and studying neural networks that could automate tasks that depend on human memory and experience. But there was a breakdown: our NASA customers frequently complained that our engineers and scientists failed to make their deliverables.
This was a major issue, since the research funding for the institute came mainly from our individual contracts with NASA managers. Failure to make deliverables was a recipe for non-renewal and loss of jobs. NASA managers said, “your work is of no value to us without the deliverables we agreed to,” and our scientists responded, “sorry, we can’t schedule breakthroughs.” This disconnect seemed to be rooted in the gap between what engineering and science schools teach and the realities of customer expectations in the workplace.
This extract from the review brings up a smaller issue. The notion that we can't possibly estimate when we'll be done or what it wil cost. And the popular notion that...
Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before.
The rest of the book review speaks to the new engineer gap and how it is being closed, with these principles (I've included the one most interesting to me personally)
- Become competent at engineering practices and technologies.
- Learn to be a designer—someone who can propose combinations of existing components and technologies to take care of real concerns.
