iancackett

Good point. I think most Java projects use only about 2% of Spring!

There is certainly a place for "a little coding", as you put it. I used to work in an investment bank where traders would write their own Excel macros to perform duties it would've taken months for them to get IT to implement. But building most production-worthy software is not what "learning to code" is about. I guess I'm just trying to re-draw the line. Wouldn't want to stop anyone coding :-)

I kind of agree that there is a place for coding without becoming a developer, but what these recent "code schools" seem to be doing is trivialising software development itself. I certainly wouldn't want to stop anyone dabbling in coding, singing, learning a language, etc... but we wouldn't want to confuse that with taking any of those pursuits to a professional level, which is something else entirely, and not quite so "easy".

Thanks for the share, rubikscube. Much appreciated!

Wow... this hit Hacker News a second time! I agree, perhaps we should be pushing more in the direction of engineering... at least for certain kinds of project / product. At startups, there's definitely a push in the opposite direction; towards Agile, less formality, etc. I suspect the two approaches to continue diverging.

Great comment, thanks. I agree on the difference between a Computer Science degree and a Software engineering degree. I have the former (Comp Sci), and that's the premise for my article. Many folks were never taught the strict definition of "engineering", and believe that's what they do as software devs. I know that's not what I do.

I'm simply going with the definition of true "engineering" taught to me as a software engineering major at university... and specifically that we don't do that formal definition of engineering. Of-course, other fields (mechanical, civil, etc) don't always follow all the formalities either, but there are ways of modelling that simply aren't available or aren't used by software engineers.

Great point. Modelling and understanding what's being built are certainly important aspects of engineering.

Yes, very true. And I am also comparing the startup flavour of software development (which I am involved in), rather than perhaps other flavours, such as finance, health care, etc.

Great point!

Great points, thanks. I agree, there are perhaps more similarities between software development, and traditional engineering, than I figured.

Very true!

Great point!

Great point. Perhaps we'll be able to classify certain software practices as "engineering". Maybe even stricter forms of Agile. It would be great to head in the direction of it becoming engineering, rather than in the opposite direction.

That's a great point, and one of the reasons I was originally taught it isn't "engineering", strictly. I think we do a lot of what counts as engineering. But, you're right, we aren't formally certified as an engineer. Perhaps that (and the required rigour) will change.

Some great points, thanks!

I think "we're still figuring a lot out" sums it up for me. Perhaps it will become more rigorous over the next few decades. Perhaps we'll start to see more parallels with physical engineering.

You're right that quality is the key.

As I'm commenting elsewhere, this is true... I didn't acknowledge that other physical engineering projects do indeed suffer from some of the main problems. What's missing in software engineering is the rigour and ability to reason so precisely about what's being built. I was originally taught (on a Software Engineering degree course) that it doesn't formally fit the definition of engineering, and I've not seen that change much, but I'd agree the definition is certainly up for grabs, and perhaps extension to include modern software practices, such as Agile.

Yep, you're right... I'm forgetting that physical engineering also suffers from some of the same problems. The thing that it adds though is a level of rigour, and ability to reason about the project, that we're still struggling with somewhat in the software world. Believe me, in 20 years since I was taught it's not strict "engineering", I've yet to see that change much, other than in safety-critical and cleanroom projects.

That's a good point. I guess that counts as the kind of "rigour" I was taught we're missing in software engineering. The definition could perhaps be extended. We do things differently, but maybe it's still engineering.

Having studied Software Engineering as a degree, I can assure you they teach software engineers the definition of "engineering", and stress that we are practicing something else or, at a stretch, an extension of engineering somewhat different from civil or mechanical. I realise that building projects probably suffer from many of the same weaknesses, but the degree of rigour, and ability to reason about the project, is definitely way higher than on software projects. I knew a few civil, mechanical and aeronautical engineers, and they tend to agree. That said, definitions like this can be hard to pin down!

Wow, so, Hacker News... didn't see that coming. Thanks for the comments, good and bad, folks.

One thing I certainly agree with: Regular physical engineering isn't entirely free of many of the problems I mention with software engineering, but the ability to understand and plan more effectively does appear to be there. The complexity in physical engineering does seem to be a little more tangible. I know a few civil and mechanical engineers, so I'm not plucking this from my behind ;-)

In terms of the definition of engineering, and the argument that software engineering isn't "engineering", I was taught this way back at university (City Uni, London), in their Centre for Software Reliability, and it's something I've largely agreed with. However, I think it was mainly used as a warning mechanism for newbie software "engineers" like me, to let us know that what we do is significantly different from other forms of engineering, in terms of the rigour. Perhaps it still deserves the title, but I guess that's a longer discussion.