My university offered both a CS degree and a Software Engineering degree. While both open the door to tech jobs once in industry, the contents varied in the upper years. The software engineering one started with common engineering courses, then common CS classes, and finished with project lifecycle classes such as QA & requirements gathering. In contrast, the CS program started with a mix of core engineering and science classes, progressed to the common CS classes, then went further into advanced CS and algorithms classes.
You are never taught how to build quality software
411–420 of 500 posts
Re: You are never taught how to build quality software
#412Earlier quoted context omitted.
There's a massive gap between taught at CMU and taught at most universities. And even if it is taught, it's usually outdated or focused on very literal stuff like how to write web applications. I'd have killed for a class that actually focuses on implementation, on teamwork, on building complicated systems.
I've wished that students would be required to hand their semester long project to the person next to them each week.
Not each week, but at my university, they had enough focus on the science part that most semester long solo projects were semester long and solo only in name. Students were assigned some component or incremental stage of some larger project spanning years and multiple PhDs, not some assignment for assignment's sake. That certainly did not make them perfect learning environments because students were left to their own in how they solve cooperation (postgrads running those macro projects might be considered PO, but not technical leads, and just as clueless as the rest) but the "pass on to the next each week" approach would have exactly the same gaps.
Re: You are never taught how to build quality software
#413The problem is that while experienced software engineers probably do know how, and would even like to, management never approves enough time for doing so, and so here we are.
Re: You are never taught how to build quality software
#414Earlier quoted context omitted.
I took one of these kinds of classes in my masters program this year. They were totally obsessed with UML. It would be nice if these classes could move beyond dogma that is decades old.
Got my MS in SE at DePaul University in Chicago. Wrote more UMLs for those classes than I’ve done in 10 years of actual software development.
While I'm not suggesting that UML is necessarily the solution, I hope it's not, but the observation that so few developers touch anything that just looks like UML is a good indication that a lot of software is in fact NOT designed, it's just sort of hobbled together from a few sketches on a whiteboard.
Re: You are never taught how to build quality software
#415Sources?
References?
It sounds great - i am sure this has been studied. Anyone have any studies that have been done?
Re: You are never taught how to build quality software
#416I really liked the umbrella demo :) Here's my take on testing[0]. I write Quality software. It's a matter of personal satisfaction. Many folks can't really tell the difference between relatively good software, and very high Quality software, but the cost difference can be quite large. We don't get rich, writing top-shelf software. The issue is, in my opinion, that we don't even produce much "relatively good" software…
Thank you for sharing. I just read through several of your blog posts and especially resonate with your “evolutionary design”. The idea of integration tests/test harness first over unit tests makes a lot of sense to me too. As a one person team myself, the “art” of creating quality software products, at speed, is revealing itself and is quite fascinating.
It’s not everyday that devs like me get to learn from someone with as much experience as you have. Thanks again for sharing your knowledge!
Re: You are never taught how to build quality software
#417We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…
Rose Hulman is an undergraduate teaching school that also has a distinction between a Software Engineering Degree and a Computer Science Degree. The Software Engineering degree takes a few less math courses and instead takes classes on QA/Testing, Project Management, and Formal Methods
Re: You are never taught how to build quality software
#418We do teach these things, they are just not core CS topics, but rather in other areas, relegated to electives like a software engineering course. At CMU we have entire Master's program for software engineering and an entire PhD program (in my department). We teach exactly the kinds of things the blog post is about, and more. Software Engineering is a whole field, a whole discipline. I get that this is a blog post and…
It was a mandatory class too in the univ I attended.
What was not taught about were the techniques of QA's, the variety of tests and design pattern enforcements that would reduce QA cost by tenfolds.
Re: You are never taught how to build quality software
#419Earlier quoted context omitted.
Do SE classes teach debugging skills? I hope they do. So many times I have seen people try random things rather than follow a systematic approach.
But debugging is about "trying out random things". You can call it a Monte-Carlo tree search is you want to sound smart. And I don't feel is not something that is worth teaching in universities, because it is 90% experience and for me, the point of universities is not to replace experience, just give enough to students so that they are not completely clueless for their first job, the rest will come naturally. What un…
I suspect that GP was talking about some notetaking tactics to systematically narrow things down while throwing educated guesses against the wall. Because so much of debugging is running in circles and trying the same thing again. No amount of notetaking can completely remove that, because mistakes in the observation are just as much an error candidate as the code you observe, I'm convinced that some "almost formalization" routine could help a lot.
Good points on the tool side. While "debugger driven development" is rightfully considered an anti-pattern, the tool-shaming that sometimes emerges from that consideration is a huge mistake.
Re: You are never taught how to build quality software
#420A software business is made when someone needs an automated computation and buys a program from someone else.
The buyer has a specific requirement, which is distilled into a specification. The specification is implemented. Implementation that doesn't match with the specification is a bug.
Now in order to verify the implementation's correctness relative to the specification there must be a QA.
The idea that people forgets to add QA in the software development process is wild because it means people are forgetting how to conduct business.