Real Software Engineering.

Thanks to Willis, I stumbled on this talk on "real software engineering". The main thesis is that software engineering isn't really an engineering, since it doesn't "work" like other engineering. That is, the processes we call software engineering do not ensure success like in other engineerings. I'm not sure if I would call this the major distinction between software engineering and other engineering.

He also talks about how software system are often a lot more complex than the products of other engineering. This makes ensuring quality much harder. Using mathematical models is impractical, so testing is the only real way to ensuring quality. Further, this testing has to be done very often and early, in order to minimize testing costs.

He makes an interesting distinction between the engineering processes between software engineering and something like structural engineering. In structural engineering, the engineer designs the final product and encodes that in some design document. This document then goes to laborers who actually create the final product.

Software development follows a different process. It seems unlikely for this workflow to apply to software engineering, since we haven't found a good way to express a design completely and unambiguously. Instead, the source code acts as the design document. It is, after all, a very specific document encoding the exact project requirements. With this, the language compilers become the laborers who build the final product given a design.

I think he missed an important difference between software engineering and other engineering - changing requirements. I don't think any other engineering has to design systems that must be flexible enough to withstand customers adding, removing, and changing requirements at any time during the project.

I think the origin of the Waterfall Method is hilarious. In 1970, Winston Royce published a paper about the Waterfall Method. His main point was that projects using Waterfall were "doomed" to failure. However, the paper was poorly written, and it is easy to misunderstand him and think that he recommends Waterfall. This is exactly what happened. Too many managers simply looked at the diagrams that seemed to make a lot of sense. They completely disregarded warnings. In fact, on the second page, Royce presents the first ever Waterfall Diagram. The very next line reads: "I believe in this concept, but the implementation described above is risky and invites failure.". I guessed they all missed that part. *facepalm*
My favorite quote (on page 1!): "An implementation plan to manufacture larger software systems, and keyed only to theses steps, however, is doomed to failure."

So lesson: If you are going to implement some new idea from a paper, read the full paper!

Teaching real-world programming

MIT is has a very cool course on real-life software development. The course involves 4 major group projects, as well as code reviews by senior developers in the industry. After the coding is done, the groups sit down with real life developers and talk about code style and clarity in 60-90 minute sessions.

I think this is a fantastic idea for a course, and I think it'd be great for Waterloo to adopt something similar. Getting input from real life developers is invaluable, and I am starting to think a lot of our professors can't offer that. For instance in CS 246 "Object-Oriented Software Development", our professor said something along the lines of making your own linked list every time you need one, because then you know exactly how it works. Really? This course was supposed to teach fundamentals of software engineering, and I don't think ignoring existing code is one of those. To make things worse, it's the only mandatory course CS students will have to take that talks about developing quality software for the real world. It was bad enough that we spent most of the course learning the stupid nuances of C++, and only two lectures on design patterns.

I think Waterloo could easily adopt such a program. I'm sure there would be no problem finding volunteer developers to do code reviews with the hundreds of tech companies in Waterloo.


On an unrelated note, the Jobmine Gods have been very nice to me this semester! I will be working with Karos Health in Waterloo for my Winter term. I'm super excited. Time to brush up on my Java!

First!

I now have a blag for my random thoughts. I have no idea how often I will use this, or what I will write about. Probably something relating to software development and my life. Perhaps I can use it as a portfolio as well. We'll see.

Maybe I should be getting ready for my OS midterm instead of setting up a random blog. I should get on that.