When I built my own software for my own use, I tended to try and write it starting from its very foundations; it had to be perfect in terms of code quality. Abstractions, modularity, readability... I would try to write software in a way that maximizes those aspects of my code, even for applications as simple as just reading my laptop's battery levels.
That approach might have some merit, but I'll face it: This wouldn't fly when I have a deadline.
Such is the reason why we even have subjects dedicated to project management, especially when developing applications that are... non-trivial; designed for an actual userbase, i.e. client(s), and does more than just do the most basic of tasks. Not only that, but such pieces of software usually requires a whole team; one person can only do so much. How would that team be managed, then? And how could said team work towards a client's requirements, some of which may be ill-informed, unrealistic, or otherwise contrary to what the team has already finished doing?
Now I have to take project management seriously. Over the years did I hear so much about terms like "DevOps", "Agile Development", "CI/CD", etc. online, and I thought I don't have to learn it until the day comes where I get to the level of actually needing to take it seriously. That came closer than I thought!
I usually write software starting from the most "fundamental", i.e. non-user-facing functions first, then glue them together later with user-facing code. Implementing each bit of functionality during this first bit is usually quite straightforward, as it's a focused effort on one "micro-problem" at a time. But when actually writing the code meant to interface with how a user actually uses a program, where do I even begin?
Diagramming is a concept I've overlooked far too much. Almost all of my programs are designed to be "human-input-less", i.e. the only inputs it takes come from its environment. Things like configuration, the battery level of either my laptop or my mouse, the current time... I've mostly written utilities for my own use, mostly as a consequence of me choosing to use a hyper-minimalist operating system. I have to write my own clock, app bar, even bits of my text editor... Surely, I must have a massive bias. Assuming everyone is like me is a recipe for disaster. No one but my close friends uses a terminal regularly, and I've never actually made a singular program with enough complexity to warrant me looking for ways to visualize how it works.
But now, with the WebSysTech/HCI/etc project, I actually have no excuse not to use one, and the refreshers on diagrams, especially the ones directly involving our end users, come at just the right time. I knew human interaction with a system isn't actually as complex as I've treated it so far, but Activity and Use Case diagrams showed me just how much simpler things actually are when visualised like this.
There goes my fear of accepting user input... mostly.
Most of those who I aspire to be as a developer (the "thankless Nebraskan dev") like the maintainers of important software like the Linux Kernel, FFmpeg, and Git, aren't very fond of Agile development. Reading their opinions on things when I was an impressionable 14 year old may have formed a prejudice within me against buzzwords like "Agile", "DevOps", "CI/CD", whatever... Unbeknownst to me at the time, the kind of software they write is so far from the kind of software that... well, makes money, much like how we don't buy houses from the brands of hardware used to build them. They build foundations upon which business-oriented solutions are built ontop of, not the solutions themselves. Of course they'll want to build things the "traditional" way, either as a Waterfall of contributions or a V-shaped development life cycle. But what if we want to "move fast and break things", where we can afford making a few mistakes here and there, without imploding half the Internet?
"Agile" development and methods similar to it seem to be "the way" for solutions that must actually deliver features with speed. It's called "Agile" for a reason! Of course, I'm oversimplifying here, but it's a completely different world vs. a straight incremental-only approach, for example. We don't use this to build mission-critical software (the kind that makes sure no one dies), but solutions that don't need to be perfect, but we need as soon as possible. This is what the lessons about "the Agile way" taught me, that it has its place in software development.
I understand their "hate" of all things "Agile" now. They're not wrong. If anything, they're even correct that the quality of software might sometimes be worse as a result of the Agile methods. However, what I didn't understand back then, was that they didn't really hate it, but they just didn't see it to fit their needs. Agile development isn't bad, their projects just didn't need it. They tread extremely carefully so that we don't have to, and Agile unlocks the speed that their foundational work affords us.
No, no, the title refers to our "Final" work involving HCI/Websys!
On a serious note, there were many problems that we had to overcome throughout the development of our web system. My group members have done well regarding the user-facing UI, but the underlying systems, of which all of it were to be done by me, would cause a lot of stress among all of us in the group. I still feel sorry for choosing the programming language that I was comfortable in (and raving about to my peers), instead of the established one that we were taught in our previous year (PHP). Whelp, most of the points losses they took in the presentation were wholly my fault. How could they have known which code did what, in a language I've barely made familiar to them?
At least they don't harbor hard feelings against my (poor) decisions... as far as I know.