We Are No Engineers

Recorded at:

Just from looking at the title and the description of this talk I am sure I do not agree. Perhaps the author does not have any idea of what engineers do. In any event, electronic eningeers are starting to deal with more complex systems that have lots of software in them. Agile and Kanban are production techniques. Engineers, software or hardware, design to user requirements. Kanban was developed for manufacturing systems. Agile was developed by software, but many of the ideas and techniques have been around for a long time (as have I). This was a discussion we were having in the early 1980s. I mean exactly the conversation!!!

Dear Luis and Jim:

I believe that both you are right. We are not engineers and Agile and Kanbas are production techniques. software engineering (SE) doesn't recognize itself that it is a dual discipline: technical but managerial. It was invented as now it is.

A critical review of the history of software engineering shows that it is a social and political invention of those players. Yesterday was a myth but now, it's a fact. Really, software engineering was born like a bastard discipline, outside the main stream of that time in 1968 (computer sciences). Computer science (CS) would was its natural disciplinary umbrella but SE competed with CS.

More than forty five years after, both disciplines has two distinct histories and results: computer science is recognized as a true science but software engineering is a practical discipline (in a managerial sense) which is looking for its never established theory (See the SEMAT debate). Now, these two disciplines has not reconciled themself but it's necessary.

More in depth here:
Zavala-Ruiz, J. (2012). First things first: If software engineering is the solution, then what is the problem? So, what is software? Unpublished paper submitted to SEMAT Workshop on a General Theory of Software Engineering (GTSE 2012), KTH Royal Institute of Technology, Stockholm, Sweden, November 8-9, 2012.

Regards,
JZ

"How many texts can we take from a book of 1992 and say it's relevant?"

Both Knuth's Art of Computer Programming and Dijsktra/Dahl/Hoare's Structured programming are 95% relevant today.

"It's not an engineering issue that comes up and surprises you"

Yeah, I mean, sometimes I think I'm the last guy who actually designs software. On the other hand: look ma', no bugs!

I mean, you are ignorant. I would just simply ignore your words: I have engineering practices, read books on Structural Engineering and Architecture and actually can apply some of them in my life as a software engineer (yes: as an engineer).

My only problem is that there seems to be so many of you and it's so hard to work with people who just don't have engineering thinking. They can't tell you what they're gonna do, even for the simplest things.

So that's where it gets disturbing. That every year, the juniors are less and less reliable, and it takes more and more time to get them accustomed to engineering practices, to make them talk about concepts, architecture, to make them think about technical and user requirements, to make them think about how engineering is made.

On the other hand, it's not a month ago that one of my former junior was awarded the highest leadership role in one of those multinational development companies. Basically everyone I trained in the last 5 years and survived are leading figures.

So it calms me down: yes, it's harder and harder to make engineers out of the SE students. But once it gets done, they rule the industry.

Simply because engineering works, chaos doesn't.