View Full Version : Awesome conference on Software Engineering
02-21-11, 03:47 PM
Really a must-see for all developers.
Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all.
That’s odd, because in every other field, the term “engineering” is reserved for methods that work.
What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this session, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being “anti-engineering” (as they are often described), actually represent the best of engineering principles applied to the task of software development.
You just can't miss the story he tells about the origins of the Waterfall model. :D
02-22-11, 08:06 PM
Watched most of the video. I really have to agree with his final point. When we were sitting in introduction to programming I couldn't help but wonder why we needed flow charts and pseudo code to take the place of actual code. The code itself is able to contain all of the parts needed to create a program and in itself can create organization by using proper coding.
02-23-11, 01:20 PM
Organizing yourself before coding gets more useful as project complexity grows.
It's good to understand how all the pieces fit together and how they are going to interact before trying to shape them.
Past that point, coding is better than pseudo coding.
Pair programming is great too if both are really participating.
02-23-11, 05:56 PM
I really love what he explains at 42:30... I just can't recommend this video enough. It's so eye-opening! I wish all university teachers would see this.
That is a great video. I passed it to several other developers at work and they thought the same.
I told the VP he should make it mandatory viewing for our BAs and PMs.
03-11-11, 08:41 PM
Being a Software Developer for many years before I retired I think I have some understanding of software development. And although I think what's typically taught doesn't work I will say this video didn't seem to help anything. I can't offer the answer but I don't think this video is worth the praise it's being given.
Some of my products were sold retail in more than one country so I don't think I'm a complete idiot either. I have some strong feelings about what's wrong but I don't think this is the time to share it. But I will say one thing, it seems to me the more education you have in how to develop software the further away from the real answer you get.
Simply put, good software engineers working together creates good software, not the structured and enforced environment I worked in during my last few years. The only thing it did was create a time table you were forced to follow and that created software the customer didn't like, as in buggy.
What I seen was forced releases that didn't get the testing they needed to produce good software, just praise for the boss because they were released on time. A software or hardware bug is like a fish, how long does it take to catch it, as long as it takes. And schedules don't work that way. Ha. I could go one but why, the problems are so entrenched in the development process they will probably stay there forever.
04-09-11, 01:43 PM
Well, that's in part what the video states. You can't expect to create software as bulding bridges. You don't have "bugs" when building bridges (unless you use bad materials). You just put everything in order and you are done.
Software is much closer to an art, as stated in the video, but it still has engineering things. Definitely having to comply with a deadline for a release usually makes bad software, and also angry developers.
I think the main point of the video is that you shouldn't focus on creating tons of documentation of how the development will be expecting to later "simply code" what you designed. The code is the real documentation, and your design should always keep at a high level. You should only do it a low level if the programmer has the IQ of a monkey, or if you are dealing with a really complex algorithm (not very common).
Something people always miss when it comes to comparing software products to other engineered products... software doesn't contain material defects or manufacturing defects. It doesn't wear out. So it doesn't have those classes of problems.
However, it often fails in ways very similar to how other complex systems fail: design flaws. Software crashes or exhibits bugs when the system encounters an unanticipated set of inputs and doesn't handle them well.
This is the exact same thing that's brought down many structures- for example, the Tacoma Narrows Bridge. The guy that designed it had a theory about how to optimize suspension bridges. He created a bridge for light traffic with an extremely thin bridge deck. It worked great, except he didn't anticipate the influence of a factor that wasn't significant on previous bridge designs: his super-thin bridge deck acted like an airfoil. The upward loads imparted by high winds tore the bridge apart. That's one hell of a "bug".
Both space shuttle disasters- same thing. Complex systems interacting and failing in complex ways... i.e. the foam falling off the side of the external tank and punching a hole in the thermal protection system at a critical point. No one anticipated that in the design of the vehicle- it didn't wear out; a design flaw brought it down.
Deepwater Horizon, Piper Alpha, Three Mile Island, Chernobyl, Ford Pinto, etc, etc, etc- all killed by flawed designs. This is the same class of defects that produces most software problems. Software and bridges have more in common than most people realize, the problem is most people pick the wrong analogies between software & physical products.
vBulletin® v3.7.1, Copyright ©2000-2015, Jelsoft Enterprises Ltd.