How about "Building an End-to-End Software Solution - 101". Going through the entire development workflow (idea, design, prototype, beta release, delivery, and iteration). One of my good friends is currently going through school, but in the back of my head there is this nagging thought, that he will not learn what's needed for today's market.
> Going through the entire development workflow (idea, design, prototype, beta release, delivery, and iteration).
That sounds like what I was taught in school. Never used it. I'm just glad the waterfall model is dying.
It is kind of funny, me and all of my peers were required to do the whole requirements, design, implement, verification, etc thing. But nobody did, nobody.
Everyone did the same thing: Requirements for one small part, implement, verify, and then write the design document at the end to match the implementation. Repeat.
I'm really glad things like agile are here, not because they're magical solutions to all of life's problems, but because they're inherently compatible with how people ALREADY WORKED. Waterfall felt like a boat anchor, causing teams to get indefinitely stuck in the design phase (or to lie a bunch to effectively skip it entirely). Agile allows you to go away, get it 90% down, and then iterate, iterate, iterate until everyone is happy.
To be honest waterfall always felt like a programming methodology created by people who never programmed. It was like they took the method for building a bridge or a skyscraper, and applied it to software blindly. Agile methods feel like something designed by people who have actually programmed and know how they like to do it.
You're living in a different world than I am. In my world, most organizations don't know the software they need until they figure out what they don't need in UAT.
The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.) Then, they think they know exactly what they need, but then they won't figure out what they need until UAT when the real users finally see the system and point out the business rules that were considered unimportant.
So, why not iterate quickly, developing the software in one of two orders:
* If one portion of the system can be used independently and generate value, why not build that first and get everyone using that?
* If the system cannot provide value independently, build the MVP of the first screen they will use in the workflow and a view-only portion of the second screen? Then get real world users to tell you what they absolutely need before calling it done.
Once the first screen is done to their approval, then you take stock of the budget. You tell them there is a balancing act between cost and scope, and everything flows from there. (Or, you find that the value can't be realized and bail to another project.)
Hopefully this doesn't come off as patronizing, but given you're a programmer (had a look at your profile), then yes we definitely live in different worlds. I work with a variety of people who have very little empathy for developers, but effectively hold the purse strings on technology decisions. These people (which largely outnumber programmers btw) see the world in black and white -- things either work or they don't. Software development to them is a black box.
> The exception to the rule is when they're replacing an existing system (or consolidating multiple systems.)
This is pretty much 90% of the software systems and projects that exist today. Don't let the headlines of TechCrunch fool you. The world outside SV doesn't sit in Google, it sits in terminal screens and mainframes. All that money SAP, IBM and Oracle is making is all made by replacing existing systems (whether software or pen and paper). The people making the decisions don't care about MVPs or what screens look like. They want to increase efficiencies aligned with the objections of their role and not get fired for doing it. When I tell a trader at an asset management company they can't enter in incorrect values for a stock trade because we'll need to fix the data quality issue on our backend, they tell me "f--- off" because they'll simply pay their way out of that discrepancy.
So I hear you, but what you're suggesting exists in very few organizations (globally) or in a vacuum.
They're replacing the existing system because the interaction of programmers and users made an unusable system that didn't account for the business needs. Unfortunately, the people in control of the pursestrings don't have the same day-to-day perspective of the people actually using the system. I've seen documented processes be completely divorced from reality. The real challenge in these systems is uncovering the true business, and the true business isn't understood except as a collective.
It is challenging to tell a director that they don't understand their own business, however.
I've worked in a lot of internal IT shops throughout my career, and it is only recently that I've worked on B2C applications. That's why I explicitly say that replacing an existing system requires more iteration, not less.
How many times have you seen a user exploit a bug to get their work done and be angry when it's "fixed?" The real bug is that the business didn't understand their own process.
My job, when I was in internal applications, was to cut through the bullshit and really understand how the business was run. And anyone who thinks they can analyze the problem up front and give a precise estimate for how long it will take is delusional.
> And agile was created by people who don't understand that most organizations need specific software developed on a specific budget.
That's an odd criticism of agile. The whole point of agile is to prioritize so that the important stuff gets done first and does what it's supposed to, so when the money runs out you've got the most important bits working the way they should.
If you've got a fixed budget, you're waterfalling and the money runs out, odds are very high that the software is going to do what the requirements said it should do, but it will be near-useless in real life.
It isn't an odd criticism of Agile. In fact, I think the criticism is that Agile views all projects as things that go on until the money runs out, at which point the user gets whatever the team managed to finish. This ignores the world of projects that have hard requirements and hard deadlines. It also ignores the world of projects where the team needs to coordinate with other software and non-software development teams.
I have not seen a variation of Agile that works well for these situations. The closest I have seen was referred to as "iterative development", where the project laid out a multi-year series of vague milestones and performed three-month mini-waterfall iterations to reach them in series.
> most organizations need specific software developed on a specific budget
And that is perfectly fine. It doesn't mean you cannot be agile. Agile is a matter of breaking it down, choosing what to work on, and verify progress. If your constrain is 4 dev team and 6 months, you plan after that. If you cannot make a somewhat realistic roadmap, you either reconsider the constraints, or are forced to move forward. In any case, with agile you know your progress compared to the overall roadmap every 1-4 weeks depending on your resolution, but it's infinitely better than the waterfall where the mangers throw the spec over the wall to the dev team, and climb over to ask why it's delayed after the deadline.
It's a methodology from when you had to schedule time for your program to run and at a minimum 24-72 hour turnaround on the smallest change. In that case it's worth taking extra time to verify things on paper and institute heavy practices to ensure correctness. Then you can just type "exec" in a terminal that completely changes the equation.
Same here. We had to design and write a significant real-world application. You could suggest your own idea or take on a project that the profs had found through their connections with the business world. Either way, you had to convince the professors on the committee that it was worthy of receiving a full course's worth of credit (though most people wound up spending far more than that amount of time on it).
We had that at my community college too, we worked along with an government organization to produce software for them. Unfortunately most of our coursework involved writing documentation and doing presentations, so the software side of things wasn't as useful as it should have been.
The software engineering degrees here in Australia (not CS) have you do that a number of times. I wish I had studied it, but B.Sci in Maths/Chemistry and half a law degree was still quite enjoyable.
Oh god. We had that too. Course was called "Software Engineering". It was pretty much the most horrible thing I experienced in CS and for me sealed the deal: I was never ever going to be a software engineer. So glad when it was over and the next block was about actual science again.
In hindsight, I have to admit I did learn a useful thing or two.
(unfortunately those things are still only useful in software engineering)
"Software Engineering" is actually offered as a degree at many institutions.. Focused more on the construction of quality software focusing on software design and development processes over how to code and analyze algorithms. I'd almost call it applied cs.
Yeah, at Berkeley the class's intended subject matter is exactly that kind of design and development process best practices, taught by running a semester-long project from design through completion. There's just not a separate degree for it.
