11–20 of 59 posts
His argument against calling it "engineering" is because we don't properly estimate our time? To me, engineering is a way of thinking, it's all about problem solving.
"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case." Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more…
While bridges can fail after 50 years, the general state of many software applications (particularly in enterprise software) is seemingly less good.
I primary issue is lack of standardization and rigor in the field that allows for quantifying allowable defects, test coverage requirements, and understanding of failure scenarios. Simply put, so much is played very fast and loose. Fragile systems are sometimes built in haste on fragile foundations.
In say, electrical and building codes for houses (not engineering so much, but applicable), there are established standards for protection of consumers and standardization of work. In software, usually these don't exist - or they exist in small legal areas like PCI or HIPAA, and don't really explain how the software is built either, but only some of the properties. Not only do building codes exist, but the similar codes and standards exist for the parts the technicians install.
Rather than codify the practices of the craft that firm things up, everybody's still trying to figure out what those practices are. And maybe that's ok. Bridge building has been done for thousands of years, and software has been done for far less than a century.
We are still figuring a lot out. Yet, at the same time, I don't think we remember much from history, software that has "nailed it", and analyze what works and doesn't.
Software is also kind of not engineering because it's an expressive medium to some, kind of an art, hence the application of "craftsmanship" frequently applied. We are sometimes inventors, sometimes engineers, sometimes sometimes carpenters, sometimes plumbers.
These are all valid fields, but I do want for greater engineering rigor over the long haul. I think it would make things less stressful. But right now, we (as the people in the industry) are doing all these breadth first forays to figure out how software is built - sometimes getting stuck in local minima and maxima until we can upset an ideology enough to try something new - and that's partly why it feels like it does. We have a lot of people with different experience levels and different specializations, and often conflicting opinions, where sometimes none are clearly right or wrong.
On the other end, business also needs to change. A bridge is never "sold quickly", it is sold and then takes as long as it takes. Electronics can be pitched heavily, but the cost of field replacement is so remarkably large it must be gotten right the first time. However, software can quickly be replaced on the fly. More so a problem if you are working on a .com than on firmware, the need for rigor is reduced and engineering deliverable is more controllable by the desires of the business side.
Ultimately, it's still a remarkably new industry, and it itself is able to evolve quickly, as we are not realing dealing with the rules of chemistry, but rather conceptual ideas and logic. Logic and ideas are fuzzy complicated beasts.
>projects delivered precisely what they said they would, and in the timeframe they originally promised. Those factors are " project management " which include concepts like "scope", "budget", and "critical path". It's arguable if those are "engineering". They certainly affect engineering. (And likewise, some engineering constraints can feed back into project planning and feasibility.) In any case, project planning is…
I think "Software Engineer" is just a title given by a place of employment. However, for those who genuinely believe themselves "Software Engineers" I would ask: What was the outside institute that certified your software engineering program? What professional exams did you take in order to be licensed as a software engineer?
Estimates aren't so much of a concern for me as quality. While bridges can fail after 50 years, the general state of many software applications (particularly in enterprise software) is seemingly less good. I primary issue is lack of standardization and rigor in the field that allows for quantifying allowable defects, test coverage requirements, and understanding of failure scenarios. Simply put, so much is played ver…
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.
"Software engineering estimates and plans often fail to live up to the reality that follows. It seems to be the only engineering discipline in which this is regularly the case." Is it though? I live in Boston, home of the notorious* Big Dig[1]. While particularly egregious, it's far from the only large-scale civil engineering project that's gone off the rails. In fact, I'd argue that until fairly recently, many more…
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 pro…
I think "Software Engineer" is just a title given by a place of employment. However, for those who genuinely believe themselves "Software Engineers" I would ask: What was the outside institute that certified your software engineering program? What professional exams did you take in order to be licensed as a software engineer?
Sorry, I meant to say software architect .
>projects delivered precisely what they said they would, and in the timeframe they originally promised. Those factors are " project management " which include concepts like "scope", "budget", and "critical path". It's arguable if those are "engineering". They certainly affect engineering. (And likewise, some engineering constraints can feed back into project planning and feasibility.) In any case, project planning is…
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 c…
That's only true if you choose for it to be. There are ways to formally prove that your software is correct but they require a large time tradeoff. For example, the software in the chip in your car has gone through as much engineering rigor as a bridge. Alternatively, look at a cheap toy produced in a shitty factory in an undeveloped country. It will have parts in it that were designed by a mechanical engineer but they choose to be less rigorous to keep cost savings low and as a result you get a toy with "bugs" in it.