The Lounge - CodeProject

First Prev Next

Re: What does software engineering look like, in practical terms?

bkebamc21-Jul-16 6:41

bkebamc

21-Jul-16 6:41

The Software Engineering Institute at Carnegie Mellon Institute had a long history of attempting to justify the application of "engineering" to software development through the Capability Maturity Model. The model recognized that software, as a developing discipline, lacked the "best practices" and "working methods" that allowed older engineering disciplines to create qualification exams. So the CMM codified management practices that would allow organizations to discover and document those practices and methods.

This was all swept away in the internet craze and economies of scale driven by zero cost of distribution. Software engineering practices are the competitive advantage that keeps Microsoft and Google and Amazon in the money, and they are not likely to surrender them. This is evidenced by the surrender of IP to open source. It doesn't make a difference whether you can get the code if you don't have the discipline to do a thorough V&V of the product as a whole - nobody spending cash money is going to trust what you wrote.

Where this has led, in the C# world, is to a steady drip of language features that allow coders to do their work faster. This manifests in (C#) attributes in the persistence framework and keywords that simplify threading and make properties behave like public (class) attributes . The upshot is that hackers can hack faster (including thinking of asynchronous processing as sequential logic) because Microsoft does the engineering behind the scenes to ensure that signals are produced and work-arounds available when something unexpected happens.

The paradox that should be recognized is that the engineering is organized to allow most developers to avoid engineering. Except in control systems, time-to-market is king, and the APIs provided by the major players ensure that application failure results in lost business, and not consumer fraud.

Eventually this will work its way out, because ultimately its engineering practices that allow IP to carry over from generation to generation. It's only those companies that do engineering that will survive the retirement of their lead developers.

Re: What does software engineering look like, in practical terms?

Kirk 1038982121-Jul-16 9:30

Kirk 10389821

21-Jul-16 9:30

Marc,
You pose an interesting question, and the answer is...
Id Depends...

Okay, for smaller pieces we gather the core requirements and iteratively get things finished.

For more complicated ones, we actually split it up into pieces, and then apply engineering concepts ONLY where needed (are we use MQ, enquue, or our ownque). Leveraging previously well working designs (kinda like using patterns), but we do NOT share the code, we copy it (unless we already made a library).

Sometimes we shoehorn a solution into something we already have working (leveraged an existing DB that the clients had access to, but now for a different project, which turned out to be useful later in the project when they actually needed to show some of that data!).

The goal is KISS. Can I explain it in 30 seconds. Can anyone identify the single points of failure? How resilient does it have to be? (If it goes down, will it halt production on the floor).

Then, each box is treated appropriately. Many solutions are NEVER a single EXE. We often have daemons, services, GUI/Clients, and intranet/html.

We apply different levels of engineering to different layers. We mandate logging, and indications if we are running in Production, Staging, Test or Developer environments.

We apply code reviews, and sharing of best practices (removal of worse practices).

Did I learn any of this in College? Yes. In fact, my late professor challenged me to write a simple program: Add 2 numbers. And then guarantee it's correctness. Warning me that I was not allowed to make any implied assumptions. All assumptions had to be stated. (Both numbers had to be integers in the range of 32 bit integers, and adding them together cannot exceed a 32 bit integer, etc. etc. etc).

And I failed.
I Falsely assumed the hardware would add correctly, without listing it as an assumption.
I argued that was unfair. A few months later the Pentium F-Div bug showed up. And he rubbed my
nose in it. (BTW, they built a computer, he was on the team, and they had a cold soldering joint on one of the data wires, and it was causing the math to behave funny, which is why he uses it as an example).

In the process, I was taught to think WAY BEYOND my software. I find it incredibly helpful. And I have had the experience that Power has been questionable, Hardware has issues, the definition of daylights savings time changes, and upgrades cause old working code to suddenly break.

We work on a layer of assumptions that is simply astonishing.
We build software on an even bigger layer of assumptions.

Kirk Out!

Re: What does software engineering look like, in practical terms?

SeattleC++21-Jul-16 12:06

SeattleC++

21-Jul-16 12:06

It's not dead. Just resting...

The root book of the software engineering movement is (IMHO) Fred Brooks' The Mythical Man Month. He wrote that book about experiences he had in 1967, and spawned a whole sub-discipline of computer science. Only, we still haven't learned the lesson fully.

Do developers always use all available tools from software engineering? No, don't be silly.

Do mechanical engineers do a stress analysis on every box they design? No. Why should they? Well, should they? Yeah, sometimes.

People rush right to coding for a variety of reasons; they think the problem is easy. Their manager is pressuring them to produce. They're human beings, who are lazy when they can be. It doesn't matter to customers if the code works right every time.

But the fact that some devs are lazy and some managers are ignorant hardly means software engineering is dead. Somebody is writing software for space probes, commercial aircraft, and nuclear reactors. And these things fail less frequently than they used to. Some web sites have performance so rock-solid that you don't even think about them going down. These are places where software engineering is being practiced. People whine about how these companies are so bound up in process that it's impossible to get anything done...anything, that is, but rock-solid quality code.

Re: What does software engineering look like, in practical terms?

mbb014-Aug-16 4:59

mbb01

4-Aug-16 4:59

You can't call it engineering until some objective measures can be applied to the whole endeavour of software development; of which there are very few.

Mathematics and science does factor in some ways (e.g. code metrics or relative performance of algorithms) but taken out of context of requirements, design and success - in the business sense - not that much help.

To put it another way, there is no way to observe an existing project and predict it's outcome, even with a margin of error. You can't observe a software developer and objectively measure their performance either. Nor can you apply any true measure to a team.

To describe software engineering as dead, misses the point. It never was alive as an engineering discipline because the basics have never been discovered let alone applied.

At the moment it is an artistic endeavour. The best analogy I've come across is the comparison to a team sport where science helps, but cannot fill in for the human factors.

Frustratingly I'm not an academic so I'm not familiar with any formal studies, but I do know some are being made. However, the studies I have read about don't, IMHO, control the myriad of variables correctly or mitigate them through wide statistical sampling. Not convinced they are asking the right questions either.

If I ever had the opportunity I would perform a range of studies to try and uncover some fundamental truths about software development. For prosperity here is a list of studies I would like to see done;

1. TDD vs non-TDD
2. How effective is refactoring?
3. Does documentation help a new developer?
4. Is pair programming more effective than lone development?
5. Is it better to learn through documentation or pair programming?
6. How accurate are comments?
7. Is bug fixing more expensive than good design?
8. Is untidy code more fault prone?
9. Are some requirements more error prone than others?

Poke what?

Power Puff Boy20-Jul-16 0:40

Power Puff Boy

20-Jul-16 0:40

If you separate 'PokeMon GO' differently you could read: poke mongo
Please don't poke the mongo.

Kitty at my foot and I waAAAant to touch it...

Welcome to the Lounge