After 20 years doing this job I can confirm that building software is really hard. I’m not sure how you really give people experience with that. My courses at uni did little to prepare me for building software.
Once you have a codebase in place, things are a whole lot easier. There are far fewer decisions to be made. Really you have little choice in how to do things as the current structure dictates your options. Discussions with customers are easier too, as you’re no longer talking in the abstract.
But it’s really challenging reaching that point.
Edit: having said all that, this does look like an interesting course
I think the problem is you really need to feel the pain of a few badly organized projects to understand why we need things that seem like extra time sinks. It's hard to design a course that deliberately goes about building a project the wrong way without seeming contrived, and yet it's easy to just start writing something that ends up being a big ball of spaghetti.
> I think the problem is you really need to feel the pain of a few badly organized projects
I'd go further than that. I've come across a few programmers who had _only_ built new systems, or maintained systems they had built. You could cajole them about coding standards, documentation, unit tests, clear naming until you were blue in the face. It is pointless.
So you force them to maintain someone else's code base. Be prepared about the rants about how bad code base is, whinging about having to learn all the unfamiliar libraries, the total lack of comments, yada yada. But somehow the connection between how that programmer worked and how they worked is never made.
Then 6 months later, after a some of the intimate knowledge of their own code they were using to make maintain it tractable is gone, you move them back. Then, finally, it hits home. They improve steadily thereafter.
Yeah, I was surprised there is no mention of drift and technical debt. These are the things that make software engineering hard. Someone new will always suggest a rewrite, which is tempting but is almost always a trap and massive timesink.
You could have them build a project one requirement at a time. That's how projects usually get out of hand in the real world. But I'm not sure if a semester is long enough.
I think you can do this. You take an existing badly done code base, and ask the students to make significant changes and/or additions. After they've felt that pain for a semester or two, you discuss what causes the pain, and what choices led to that point.
> Really you have little choice in how to do things as the current structure dictates your options.
I really like this framing. The architecture of the code should reflect the flexible and rigid parts of the domain, and how they interact. A good design will let small changes in the domain become small changes in the codebase -- and large changes in the domain will at least not be arbitrarily larger in the codebase.
Software architecture feels like a very code-centric and technical thing -- and it's not like it isn't, exactly -- but it's really driven by a solid understanding of the system into which the software will be placed. Often, the pre-existing system is a bunch of humans, and people who previously interacted with humans will now interact with software. Also often, the pre-existing system is some mix of humans and software. And even if the pre-existing system is pure software, some of the internal or external boundaries will undoubtedly shift.
> But it’s really challenging reaching that point.
We as a profession need to acknowledge that not everything is "solved" by software, and that we really need people with design experience, human factors experience, and the ability to distill the domain into something that can be addressed by software engineering. I think "reaching that point" is predominantly led by these factors, and not technical excellence in the strict sense.
It's amazing they have a screenshot of FreeCol in there! That's a Java game I've submitted bugfixes to, like fixing multiplayer, in just a few hours, despite having barely any Java experience, because it's so debuggable and ordinarily architected.
> But it’s really challenging reaching that point.
Choosing opinionated and well supported languages & frameworks is essentially the lesson there, and they'll probably finish that in one week.
The real difference here is that this course does not aspire to cram leetcode, which is what you're actually evaluated on if you get into Software Engineering. In that framing, they are adopting an extremely contrarian and risky position: if their students perform worse in job hunts after taking the course, and entrepreneurial / indie / artisanal software development remains hit-driven, students would conclude the course is bad in the long run.
> Choosing opinionated and well supported languages & frameworks is essentially the lesson there...
There are strong benefits to opinionated frameworks, and reaching an initial version of a code base is absolutely one of them. But the trade-off comes in the next version, when you get customer feedback, and the devs start saying things like, "No, we can't do it that way because that isn't how the technology works."
That doesn't make it the wrong answer for a MVP or a V1... but this is an academic course. I'm hoping they cover the longer-term consequences of early choices in software development. Because that is what is really hard - not getting a first working version, but maintaining delivery speed over the long haul as you realize the limits of your choices.
> Once you have a codebase in place [...] There are far fewer decisions to be made. Really you have little choice in how to do things as the current structure dictates your options.
And for these exact same reasons working with an existing codebase can make further software development a challenging process. It's all a matter of how well those past decisions line up with the present and near future which may not have been apparent (or simply not considered) at the time.
> Once you have a codebase in place, things are a whole lot easier. There are far fewer decisions to be made. Really you have little choice in how to do things as the current structure dictates your options.
You still have the choice to extend the current code, or build more code around it.
For example, you have a ticket system and are now tasked to build full-text search for it. You could try to do it within the existing code base, or to add an exteral search engine, sync that data to it, and build a shallow integration between the two.
That said, you are right in that deviating from the current philosophy of the code base is a big risk, and so a big decision to make.
> After 20 years doing this job I can confirm that building software is really hard. I’m not sure how you really give people experience with that. My courses at uni did little to prepare me for building software.
I'm kind of amazed at just how much experience it seems to take to build a robust & generalizable model for making reliably good decisions about code complexity management & problem solving techniques.
Pragmatic programmer does a decent job of it. Not perfect, but decent enough.
I'm of the school that thinks it's something you need to practice. Many software positions especially in large companies are very limited in scope, you basically just maintain and patch existing systems, rarely having to build systems from scratch. Building these systems from the ground up is what is hard but you learn what works and what doesn't the more you do it.
If you want to learn how to build software, join a start up or small company that has a healthy appreciation for what software rewrites can provide. Run away from companies that follow the never rewrite mantra. Usually saying something like you'll just repeat mistakes, its like well no shit this thing was built before I was born, if you rebuilt it with me here I could avoid those mistakes.
I'm not saying you should always rewrite, its usually better to refactor, but some design failures are hard to refactor out, have double binds or are too critical for stability woes. But systems that live forever should have unlimited quality assurance budgets for refactor and repair, very few do in this industry. Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane.
Like running a machine in a factory 24/7 and never doing maintenance but expecting it to work perfectly like new forever with no future cost incurred as eventual debt.
Of course it can be taught, it has to. The current model of expecting people to just pick it up on their own by going to school or a bootcamp isn't working.
I think a large part of the problem is that in contemporary workplaces it's becoming rare for senior talent to spend serious time developing juniors and doing so as an integral part of their job rather than merely within the scope of some mandated "knowledge transfer" phase.
To many places are beset with pushy "deliverables" treadmills and suffocating project management. It's hard, especially in large organizations, to just "think" and be creative. Juniors need to see that, emulate it, and get meaningful feedback beyond a dumb burn-down chart.
Art schools that teach you visual art and craft is a thing. So I don’t see why it would be impossible to teach the art of building software. We just need to change our methods.
>Once you have a codebase in place, things are a whole lot easier.
You sound blessed to not have run into huge spaghetti code with no comments, no testing, violates best practices, and doesn't work for the purpose, and also doesn't compile.
After this job doing bug fixes and feature adding, I'll take new code ANY day.
Oh don’t get me wrong, I’ve worked in plenty of bad codebases. One job I walked into and on day one the two other senior devs said “congratulations, your share is these 1M lines of code”. It was a total mess. It was back in the day when coldfusion didn’t have functions and instead you called modules that accessed and updated variables in their parents/grandparents directly. There’s nothing more devilish than code that can touch any other part of system. By the time I left there I understood the domain well enough to rewrite that whole system away. I feel your pain.
I’m talking more about how to start things right so you don’t end up in that place. It’s really hard.
And my point still stands that in your codebase, it’s done. The ship has sailed. There’s some comfort in knowing that you’re just going to have to make the most of the restrictions you’re working within (small comfort, I know).
Personally I feel like our software development methodologies/technologies/tools are drastically underequipped to handle the complexity of the systems we are attempting to build. I'd estimate we'd maybe be at the level now to handle complexity of software 30-40 years ago (i.e. 80s software), but that is not based on anything solid because in the world of software there is precious little solid to base anything of. The free lunch we have been enjoying might come to an end now that software is imbuing itself more and more to things that really matter, like human rights and safety. Electronic voting and self-driving cars come to mind as examples.
Of course another problem is that not only is software engineering still pretty immature, its use also is very unevenly distributed. While we might be able to build software somewhat reliably with state of the art tools and methods, vast majority does not use them. Not that we have much agreement on our field what constitutes unequivocally good practices. This has lead to the situation that even the basic foundational building blocks we use are usually of dubious quality.
I used to think that but now I don't think we're getting better. The more I think about it the more I see that people are equally bad at it, progress only happens by building out the tooling beneath them that allow them to build more and more complicated things, without them realizing it.
Developers have the capacity and willingness to work on a small part of a codebase and the rest has to be filled in by others in a similar situation and by tooling.
I'm a bit biased since I run an edtech company but it's very disappointing to see how hard it is to get companies and people to actually invest in education.
I took and TAed this class. I ended up dipping my toes into the open source waters with some Firefox contributions and completing the rest of the minor program including a set of contributions to Chromium. One thing that was heavily emphasized in that curriculum was how open source can be a huge asset to companies. I really took this to heart, and it has played a significant role in shaping open source strategy for containers and Linux stuff at Facebook.
Software engineering was life changing for me. I studied cognitive and computer sciences (CMU '03) - and when I graduated I realized I didn't know much about writing software.
Luckily, I found a software engineering course (Berkeley, 2005) after graduating and they let me attend without being enrolled. That professor (Kurt Keutzer) had wisdom! Literally life changing.
These engineering skills are totally different from what you learn in a computer science curriculum. I highly recommend a course like the one OP links.
Hey everyone-
I am one of the co-instructors for this course (Michael Hilton). Thanks for all the comments! I’m happy to answer any questions about the class, and I’m always looking for suggestions on ways to make the class better: AMA!
That is something we would love to do in the future, however our current videos have students voices and faces so we cannot release them for privacy reasons.
My suggestion would be to consider safety-critical software engineering: What is the difference between an autonomous driving prototype and product? From there, venture towards process stuff like ISO26262, SPICE, MISRA-C, etc. Students should learn what the purpose is behind these process standards. It might lead to interesting discussions for what use cases you want to employ how much process/tool overhead.
Thanks for sharing this content professor! Any resources (online courses/books/etc) that you can recommend for current CS students that don’t have an opportunity to take a class like this?
I haven’t had time to read it yet, but I have been hearing a lot of good things about the new book from google (full disclosure, I know the authors and they are great) https://books.google.com/books/about/Software_Engineering_at...
I also recommend following practicing software engineers on Twitter, to see what people in industry care about.
- Add accessibility and internationalization under non-functional testing types, with at least a brief mention of their importance
- Add mention of exploratory testing under manual testing as a valuable technique
- Most of your students will not be QA staff themselves in their careers, so a brief mention of the benefits and pitfalls of collaborating with dedicated QA personnel may be useful. A mention that the type of QA personnel varies highly by software subspecialty and size of the business (ranging from non-technical to CS degree holding specialists) may also be useful.
I'm glad that the lecture slides were publicly available. I was particularly excited about the slides for architecture and design docs. I just wish I could sit in to listen on lectures (or have the discipline to read through the textbook :PP).
In my undergrad, I felt that my CS classes were divided into "theory" and "systems". But, even the "systems" classes would feel removed from the modern tech industry and commercial software.
The topics that I see mentioned in the syllabus are familiar to me, but only because I surf Medium articles, and not because of my formal CS education. Yet, these topics are incredibly deep and complex. I would consider the people who work on them to be researchers in a hyper-specific domain.
The elephant in the room that 17-313 doesn't addresses is team dysfunction.
You know, the guy who insists on agile when you're about to automate a nuclear reactor cooling system. Or the one who insists on expensive message queue tech when async/await is more than sufficient. The bro that mansplains directed graphs at a PhD because she comitted the cardinal sin of being a woman. The infrastructure manager that micro-manages a developer because that manager was too lazy to stand up the test environment on time.
We all know someone like that, and after 30+ years in this industry it seems it's worse now than it was in the 90's. Back then all we had to contend with was Windows v. Unix and bastard operators from hell(1). Today it's more insiduous. Often well-dressed, veiled in charm and confidence and hiding behind a big pay check because they're adept at managing upwards. I can deal with it, which has another unfortunate side-effect - other developers want me to manage, I just want to write code.
Amusingly (sadly?) these problems(2) were identified in the 80's if not earlier. Books were written about dealing with it (2 and 3, amongst others). But still we allow the behaviour and often organisational/industry culture encourages it (fintech, anyone?).
What's there is valuable for sure. It pushes agile though. A lot. Another approach may be to provide a way for a team to choose a methodology that's appropriate for what's being built (1). It describes effective teams, but doesn't provide guidance on identifying dysfunctional teams/team members, and transforming those to productive teams/team members.
CMU has always been big on this kind of thing. I took a CMM (pre-CMMI) course there, about twenty years ago.
I tend to write stuff I architect from the ground, up. This has earned me a number of sneers, and comments about “reinventing the wheel,” but I seem to have picked up a knack for it, from many years of experience (my very first engineering project, in 1987, was a complete design of a microwave routing tool; including chassis milling, electrical design, firmware operating system, and host drivers)[0].
One of my biggest motivations, is that I “eat my own dog food.” I am usually the poor bastard that needs to back through my legacy, and figure out what I did (in fact, I’m doing that, right now). It has taught me to leave a good legacy [1].
I know this is in jest, but honestly there are two kinds of wheels: round things that everyone uses to roll around with in common/universal ways, and specific configurations of wheels like this person mentioned for microwave routing.
You probably don't want to reinvent the wheel that is SSL or UTF-8 or something ubiquitous like that, but there's actually not that much wrong with reinventing the way specific wheels are arranged and designed to work together in a domain-specific context like microwave routing (which I know nothing about). The act of reinventing it will probably teach you a lot about the domain itself, and depending on where you started in your journey, it can be quite fruitful (i.e. if you are a true beginner, then many of the lessons you learn will be things that are already common knowledge; if you are already a journeyman or expert, it's quite likely you might pick up some novel insights in the course of disassembling and reassembling the thing).
You missed the third type: those who don't know if they can do better, but are still early enough in their career to want to do everything themselves because it's exciting and they don't yet know what is worth doing yourself, and what you should trust history to have already done for you.
Readit News
After 20 years doing this job I can confirm that building software is really hard. I’m not sure how you really give people experience with that. My courses at uni did little to prepare me for building software.
Once you have a codebase in place, things are a whole lot easier. There are far fewer decisions to be made. Really you have little choice in how to do things as the current structure dictates your options. Discussions with customers are easier too, as you’re no longer talking in the abstract.
But it’s really challenging reaching that point.
Edit: having said all that, this does look like an interesting course
I'd go further than that. I've come across a few programmers who had _only_ built new systems, or maintained systems they had built. You could cajole them about coding standards, documentation, unit tests, clear naming until you were blue in the face. It is pointless.
So you force them to maintain someone else's code base. Be prepared about the rants about how bad code base is, whinging about having to learn all the unfamiliar libraries, the total lack of comments, yada yada. But somehow the connection between how that programmer worked and how they worked is never made.
Then 6 months later, after a some of the intimate knowledge of their own code they were using to make maintain it tractable is gone, you move them back. Then, finally, it hits home. They improve steadily thereafter.
I really like this framing. The architecture of the code should reflect the flexible and rigid parts of the domain, and how they interact. A good design will let small changes in the domain become small changes in the codebase -- and large changes in the domain will at least not be arbitrarily larger in the codebase.
Software architecture feels like a very code-centric and technical thing -- and it's not like it isn't, exactly -- but it's really driven by a solid understanding of the system into which the software will be placed. Often, the pre-existing system is a bunch of humans, and people who previously interacted with humans will now interact with software. Also often, the pre-existing system is some mix of humans and software. And even if the pre-existing system is pure software, some of the internal or external boundaries will undoubtedly shift.
> But it’s really challenging reaching that point.
We as a profession need to acknowledge that not everything is "solved" by software, and that we really need people with design experience, human factors experience, and the ability to distill the domain into something that can be addressed by software engineering. I think "reaching that point" is predominantly led by these factors, and not technical excellence in the strict sense.
> But it’s really challenging reaching that point.
Choosing opinionated and well supported languages & frameworks is essentially the lesson there, and they'll probably finish that in one week.
The real difference here is that this course does not aspire to cram leetcode, which is what you're actually evaluated on if you get into Software Engineering. In that framing, they are adopting an extremely contrarian and risky position: if their students perform worse in job hunts after taking the course, and entrepreneurial / indie / artisanal software development remains hit-driven, students would conclude the course is bad in the long run.
There are strong benefits to opinionated frameworks, and reaching an initial version of a code base is absolutely one of them. But the trade-off comes in the next version, when you get customer feedback, and the devs start saying things like, "No, we can't do it that way because that isn't how the technology works."
That doesn't make it the wrong answer for a MVP or a V1... but this is an academic course. I'm hoping they cover the longer-term consequences of early choices in software development. Because that is what is really hard - not getting a first working version, but maintaining delivery speed over the long haul as you realize the limits of your choices.
Deleted Comment
And for these exact same reasons working with an existing codebase can make further software development a challenging process. It's all a matter of how well those past decisions line up with the present and near future which may not have been apparent (or simply not considered) at the time.
You still have the choice to extend the current code, or build more code around it.
For example, you have a ticket system and are now tasked to build full-text search for it. You could try to do it within the existing code base, or to add an exteral search engine, sync that data to it, and build a shallow integration between the two.
That said, you are right in that deviating from the current philosophy of the code base is a big risk, and so a big decision to make.
I'm kind of amazed at just how much experience it seems to take to build a robust & generalizable model for making reliably good decisions about code complexity management & problem solving techniques.
I'm of the school that thinks it's something you need to practice. Many software positions especially in large companies are very limited in scope, you basically just maintain and patch existing systems, rarely having to build systems from scratch. Building these systems from the ground up is what is hard but you learn what works and what doesn't the more you do it.
If you want to learn how to build software, join a start up or small company that has a healthy appreciation for what software rewrites can provide. Run away from companies that follow the never rewrite mantra. Usually saying something like you'll just repeat mistakes, its like well no shit this thing was built before I was born, if you rebuilt it with me here I could avoid those mistakes.
I'm not saying you should always rewrite, its usually better to refactor, but some design failures are hard to refactor out, have double binds or are too critical for stability woes. But systems that live forever should have unlimited quality assurance budgets for refactor and repair, very few do in this industry. Managers seem to expect systems to live forever all while constantly patching with very small refactoring budgets. It's completely insane.
Like running a machine in a factory 24/7 and never doing maintenance but expecting it to work perfectly like new forever with no future cost incurred as eventual debt.
Of course it can be taught, it has to. The current model of expecting people to just pick it up on their own by going to school or a bootcamp isn't working.
I think a large part of the problem is that in contemporary workplaces it's becoming rare for senior talent to spend serious time developing juniors and doing so as an integral part of their job rather than merely within the scope of some mandated "knowledge transfer" phase.
To many places are beset with pushy "deliverables" treadmills and suffocating project management. It's hard, especially in large organizations, to just "think" and be creative. Juniors need to see that, emulate it, and get meaningful feedback beyond a dumb burn-down chart.
I was an engineer before switching to programming and despite throwing the word Software Engineer in my title, there is no Engineering.
There is developing only.
'best practices' come from Authority, not science(note at bottom). This is a stark contrast to Engineering where everything is proven with math.
(Note)We don't write in logic gates anymore, efficiency is obscure at modern coding levels.
With solo programming, everyone has to figure everything by themselves. A deeply inefficient system.
Deleted Comment
You sound blessed to not have run into huge spaghetti code with no comments, no testing, violates best practices, and doesn't work for the purpose, and also doesn't compile.
After this job doing bug fixes and feature adding, I'll take new code ANY day.
I’m talking more about how to start things right so you don’t end up in that place. It’s really hard.
And my point still stands that in your codebase, it’s done. The ship has sailed. There’s some comfort in knowing that you’re just going to have to make the most of the restrictions you’re working within (small comfort, I know).
Of course another problem is that not only is software engineering still pretty immature, its use also is very unevenly distributed. While we might be able to build software somewhat reliably with state of the art tools and methods, vast majority does not use them. Not that we have much agreement on our field what constitutes unequivocally good practices. This has lead to the situation that even the basic foundational building blocks we use are usually of dubious quality.
Developers have the capacity and willingness to work on a small part of a codebase and the rest has to be filled in by others in a similar situation and by tooling.
I'm a bit biased since I run an edtech company but it's very disappointing to see how hard it is to get companies and people to actually invest in education.
Luckily, I found a software engineering course (Berkeley, 2005) after graduating and they let me attend without being enrolled. That professor (Kurt Keutzer) had wisdom! Literally life changing.
These engineering skills are totally different from what you learn in a computer science curriculum. I highly recommend a course like the one OP links.
- Typo - "principle goals" / "principle techniques" instead of "principal"
- Add accessibility and internationalization under non-functional testing types, with at least a brief mention of their importance
- Add mention of exploratory testing under manual testing as a valuable technique
- Most of your students will not be QA staff themselves in their careers, so a brief mention of the benefits and pitfalls of collaborating with dedicated QA personnel may be useful. A mention that the type of QA personnel varies highly by software subspecialty and size of the business (ranging from non-technical to CS degree holding specialists) may also be useful.
In my undergrad, I felt that my CS classes were divided into "theory" and "systems". But, even the "systems" classes would feel removed from the modern tech industry and commercial software.
The topics that I see mentioned in the syllabus are familiar to me, but only because I surf Medium articles, and not because of my formal CS education. Yet, these topics are incredibly deep and complex. I would consider the people who work on them to be researchers in a hyper-specific domain.
You know, the guy who insists on agile when you're about to automate a nuclear reactor cooling system. Or the one who insists on expensive message queue tech when async/await is more than sufficient. The bro that mansplains directed graphs at a PhD because she comitted the cardinal sin of being a woman. The infrastructure manager that micro-manages a developer because that manager was too lazy to stand up the test environment on time.
We all know someone like that, and after 30+ years in this industry it seems it's worse now than it was in the 90's. Back then all we had to contend with was Windows v. Unix and bastard operators from hell(1). Today it's more insiduous. Often well-dressed, veiled in charm and confidence and hiding behind a big pay check because they're adept at managing upwards. I can deal with it, which has another unfortunate side-effect - other developers want me to manage, I just want to write code.
Amusingly (sadly?) these problems(2) were identified in the 80's if not earlier. Books were written about dealing with it (2 and 3, amongst others). But still we allow the behaviour and often organisational/industry culture encourages it (fintech, anyone?).
(1) http://bofh.bjash.com/
(2) https://en.wikipedia.org/wiki/Wicked_problem and https://www.amazon.com/dp/013590126X
(3) https://en.wikipedia.org/wiki/Peopleware%3A_Productive_Proje...
https://raw.githubusercontent.com/CMU-313/CMU-313.github.io/...
(1) https://www.wittenburg.co.uk/Work/Choosing.aspx
I tend to write stuff I architect from the ground, up. This has earned me a number of sneers, and comments about “reinventing the wheel,” but I seem to have picked up a knack for it, from many years of experience (my very first engineering project, in 1987, was a complete design of a microwave routing tool; including chassis milling, electrical design, firmware operating system, and host drivers)[0].
One of my biggest motivations, is that I “eat my own dog food.” I am usually the poor bastard that needs to back through my legacy, and figure out what I did (in fact, I’m doing that, right now). It has taught me to leave a good legacy [1].
[0] https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf (downloads a PDF).
[1] https://littlegreenviper.com/miscellany/leaving-a-legacy/
Those who think they can do better and those who can do better, haha
You probably don't want to reinvent the wheel that is SSL or UTF-8 or something ubiquitous like that, but there's actually not that much wrong with reinventing the way specific wheels are arranged and designed to work together in a domain-specific context like microwave routing (which I know nothing about). The act of reinventing it will probably teach you a lot about the domain itself, and depending on where you started in your journey, it can be quite fruitful (i.e. if you are a true beginner, then many of the lessons you learn will be things that are already common knowledge; if you are already a journeyman or expert, it's quite likely you might pick up some novel insights in the course of disassembling and reassembling the thing).