It's still not engineering. I mean, I can't stop you from defining engineering to include software, but there is a critical difference in the actual activity performed by engineers vs programmers.
Programming is cheap enough that (even for these hardcore "infrastructure" tasks) the cost of planning something is roughly equal to the cost of simply building it. In fact, to a large degree, the activity of planning is identical with the activity of building. So the optimal approach is always going to be to plan/build, then test.
Programmers spend their day alternately planning and building, in an interleaved way.
Engineering is characterized by problems for which the planning is many orders of magnitude cheaper than the implementation. So "getting it right" and doing all the math in a very rigorous way up front is much much more important.
Engineers spend their time exclusively planning and double-checking their work. Somebody else does the building.
So I've spent the last few months trawling through camera datasheets, evaluating OCR solutions, and building and comparing custom image transformations so that we can have a good idea of the quality and limitations of the ANPR solution we intend to deploy.
As of today only the framework of the final solution has been written, and we are finally interviewing for developers to write up the system for production (I will manage them, but am moving on to our radio code now).
Is what I've been doing engineering? If I was doing the final writing myself is it ?
To me, what you have been doing is engineering, regardless of who writes the code. If a group of people were to start writing the code without doing the preparatory analysis that you describe, and instead tried to get to a solution by test-and-fix / trial-and-error, that would not be engineering.
exactly when I worked on the Management system for the core UK SMDS network we spent 9 months designing the system and built the first version of the product in 12 weeks.
sounds like very different views of engineers and engineering. I thought engineers was people with a specific education. Engineering could be almost anything technical. You could limit it to things engineers do if you want to.
It sound strange to say that software engineering is not engineering on the base that it finishes with a complete product. That sounds like it would be engineering if we just stopped before releasing the product and called all code a blueprint.
I'm not sure that your definition works for all types of engineers. Certainly it is unlikely that a civil engineer or aerospace engineer will physically build a building or aircraft, but in many disciplines there is a lot of prototyping and iterative hands on design work being done by people with engineering degrees.
I think whether prototyping is engineering or not depends on the degree to which it is directed towards answering specific questions, or with a reasonable (reasonable as in based on rational arguments) expectation of working. Writing something in the hope that it can eventually be made to work is not engineering (these are, of course, points on a continuum, not the horns of a dichotomy.)
>what do you think NASA Boeing Etc have those windtunnels for.
To answer specific questions. Time in a wind tunnel is very expensive, and so is the preparation of the models. They are not groping around in the dark for a solution to an ill-defined problem.
Normally you blame the contractors - Back when I worked for one of the really big consulting engineers. I did reverse engineering on one project where the subcontractor had messed up some soil analysis,
Compared to other technical and scientific efforts, programming is still in its infancy. It has a long way to go before it is as refined and disciplined as other occupations.
We are getting there slowly, but it's still the wild west. Where else could you find a college dropout working alongside somebody with a PhD? I've never seen a hospital where somebody with only a highschool education and good scalpel skills was allowed to perform life-or-death surgery. But in the world of software, we routinely employ trial-and-error in trying to put the right person into the right job. And it's tough when the nature of those people and the nature of those jobs changes so rapidly.
It's definitely an interesting time to be alive. When I tell my grandchildren about how we did software 'engineering' nowadays, I expect them to laugh like we do when we hear about doctors who used leeches and magnets to cure diseases.
19 comments
[ 2.6 ms ] story [ 54.0 ms ] threadProgramming is cheap enough that (even for these hardcore "infrastructure" tasks) the cost of planning something is roughly equal to the cost of simply building it. In fact, to a large degree, the activity of planning is identical with the activity of building. So the optimal approach is always going to be to plan/build, then test.
Programmers spend their day alternately planning and building, in an interleaved way.
Engineering is characterized by problems for which the planning is many orders of magnitude cheaper than the implementation. So "getting it right" and doing all the math in a very rigorous way up front is much much more important.
Engineers spend their time exclusively planning and double-checking their work. Somebody else does the building.
As of today only the framework of the final solution has been written, and we are finally interviewing for developers to write up the system for production (I will manage them, but am moving on to our radio code now).
Is what I've been doing engineering? If I was doing the final writing myself is it ?
To answer specific questions. Time in a wind tunnel is very expensive, and so is the preparation of the models. They are not groping around in the dark for a solution to an ill-defined problem.
It seems to me that, even by your definition, the "planning" part of that is engineering.
It does not mean that mission critical software is not engineered by using various carefully selected methods and designs.
(these == infrastructure engineers)
When you have software that decides upon real life's objects, a small bug could end up in a disaster, even death.
We are getting there slowly, but it's still the wild west. Where else could you find a college dropout working alongside somebody with a PhD? I've never seen a hospital where somebody with only a highschool education and good scalpel skills was allowed to perform life-or-death surgery. But in the world of software, we routinely employ trial-and-error in trying to put the right person into the right job. And it's tough when the nature of those people and the nature of those jobs changes so rapidly.
It's definitely an interesting time to be alive. When I tell my grandchildren about how we did software 'engineering' nowadays, I expect them to laugh like we do when we hear about doctors who used leeches and magnets to cure diseases.