Talk: Real World Software Engineering

[Mark Herschberg]

About a month I ago I mentioned in this forum, a talk I was giving at MIT in January. The talk ended up getting pushed back. It finally took place on Feb 8, and went very well. So, as promised, I'm posting the talk on the web. You can find an HTML version of the slides off of my homepage at http://web.mit.edu/hershey/www/homepage.html
I welcome questions and feedback.

--Mark
[e-mail]

[Mark Herschberg]

For those not famaliar with the motivation of the talk, a abstract is included below.

Abstract:
A course 6 [EE/CS] education from MIT has a lot of value, but there's quite a bit to the art of software engineering that you don't learn in the classroom. This talk from a recent MIT graduate will give you a head start on what software engineering is like in the real world: how software engineering really works, what you need to know but don't learn in school, industry best practices, advanced software development techniques.

The talk is targeted at course 6ers (undergrad and grad) who plan on working in the software industry. All are welcome.

--Mark
[e-mail]

[R Hoffman]

Hi Mark - I checked out the slides from your presentation and really enjoyed them. I can see that this would certainly be well received.
I'm working on my MS CompSci degree right now (emphasis in software engineering), and realized not long after starting that the academic studies were not going to completely prepare me for the "real world". Formal schooling is a great start, and an important one, but there are a lot more skills needed than what are learned there.
I see this also reflected in ads seeking programmers for various positions (JAVA and otherwise). It seems like coding is sometimes a small part of the work to be done. The project design, project planning and management, and project maintenance
that go along with this are just as important, and are not something that is necessarily learned in the classroom.
Thanks for posting your presentation!
Rochelle

[Mark Herschberg]

I'm glad you liked it. One thing I should note, which I did in my presentation, but isn't evident form the slides alone, is that there is much practical value that does come from a CS education.
Case in point is an algorithms class. I've used sorting maybe twice in my career, taking about 2 hours each time. In both cases I used bubblesort (maybe it was qucksort, but I actually think bubblesort), simply because I was sorting about 20 items. So why did we spend so many weeks looking at searching and sorting algorithms? They weren't trying to teach us algorithms, but rather how to think about them, and analyze them, and apply them. CS teaches you how to think about problems. Unfortunately, they generally only have enough time to show you the tools, and don't have time to really get into using them outside of toy projects.
These tools are very useful, and without them programmers would be lost; but there are plenty more issues which CS doesn't cover.

--Mark
[e-mail]

[Eric Barnhill]

That's a nice resource Mark - thank you for posting it here.

[Peter Lyons]

Yeah, the information is great, but my favorite part of your website is the letters you get from people who mistake your site for that of the Hershey Corporation.
Hey, if I hadn't linked there from Javaranch, it might have fooled me too.

[Bryan Welch]

Good content.
I noticed what looks like a typo on slide 6 with the " � -ilities"
In the QA slide, this comment surprised me:
"Developer:QA ratio should be 2:1 or better (even 1:2)"
Two QA people for each developer? I could see that as useful toward later stages of the project, possibly. In early stages when developers are doing small unit tests, wouldn't many QA people be bored?

[Mark Herschberg]

Originally posted by Bryan Welch:

I noticed what looks like a typo on slide 6 with the " �-ilities"

That's not a typo. Look at the notes for the slide (below the side). When planning projects you should take into account appropriate "-ilities." Does it need to be scalable? How scalable? Portable? To which platforms? Available? Can you stand to be down 1 hour per week? per month? per year?
Ilities are the intangible aspecs of a system. It doesn't define how a system works feature-wise, but it does define how the system behaves. Making a web server which support 10 hits per minute is very different from one which needs to support 10,000 hits per minute.

Originally posted by Bryan Welch:
In the QA slide, this comment surprised me:
"Developer:QA ratio should be 2:1 or better (even 1:2)"
Two QA people for each developer? I could see that as useful toward later stages of the project, possibly. In early stages when developers are doing small unit tests, wouldn't many QA people be bored?

There are many reasons.
Maybe you can stagger projects and rotate QA people across projects, achiving a ratio of 2:1 for, say, half the lifecycle of any particular project.
Many companies continue to test a product even after its been released. Certainly shortly after a release (which presumably is right around the start of the next project), you tend to get many bug reports, since you're on the start of the bathtub curve. The QA people are often the first line of defense in reproducing and tracking down where the reported bugs may lie.
Depending on the skill sets of the QA personel, they could even do profiling of the system, to suggest performence improvements. Yeah, in an ideal world the developers are profiling the code as they write. The reality is they don't have the time, and QA usually puts enhanced performance lower on the priority list than "checking for bugs" (rightly so in most cases).
Along these lines, it is rare to find a company that has a test harness which they feel is absolutely complete, having all the features they need, and all the test cases they want. QA engineers can always continue to extend the harness in terms of usability and test cases.
Finally, if you subscribe to XP, then even from the start of the project, there's a need for QA, since the code is good to go from the start.
I will certainly grant you, that the actual number can vary depending on the type of software, and these numbers are by no means hard guidelines. Since my talk was aimed at students, whose idea of QA is "it compiled!" I wanted to emphasize the importance of this part of the development process. :-)

Thanks for the feedback.
--Mark
[e-mail]

[This message has been edited by Mark Herschberg (edited February 16, 2001).]