CST438: Week 7 (Week 82)

One of the differences between Agile and Waterfall software development cycles is that the Agile is more flexible while Waterfall tends to be more rigid. Agile breaks delivery efforts into sprints and is more accommodating for shifting requirements. Waterfall moves in a sequence of steps. Requirements, design, implementation, testing, and release. A large project developed using agile would see looping progressions where a piece of functionality might go from requirements all the way to testing but loop back again due to changing requirements and specifications. Waterfall is linear and makes the most sense when the requirements for a project are expected to be well-defined and stable until release.

I have seen developers get the most benefit from Agile in external customer/user facing applications. In such cases, canary and beta testing feeds back into the development cycle and encourages updates. On the embedded side, though we also use agile, I see less cycling since the hardware design is usually stable and the APIs that we provide to other developers working on userspace applications usually require fewer divisions than for example a customer facing GUI.

CST438: Week 6 (Week 81)

One of my big takeaways from this week was the "cattle, not pets" approach to compute resources. It encourages using and configuring servers and containers as easily replaceable units. It aligns with the containerization of test infrastructure that I've seen in industry. Powerful hardware can run multiple instances of isolated containers to make good use of performance advancements. What struck me most is that this isn't just an infrastructure choice — it forces software itself to be written differently, avoiding local state and hardcoded dependencies so any instance can be killed and replaced without issue. I am still learning about docker and its uses but I expect that I'll get more exposure to serverless architectures. I also think the practical implications of scaling to zero are interesting. I'll be reading more about it.

CST438: Week 5 (Week 80)

 The biggest lesson for me this week was actually more like a reminder. We should lean into smaller, faster tests whenever we can, but we should thoughtfully layer in larger tests to validate realistic, end-to-end behavior. That way we acknowledge the lesson of the test pyramid and and avoid relying too heavily on either extreme to our own disadvantage. Like so many other things, there's a balance.

I imagine working at a startup with out the big budget of a huge legacy enterprise, or anything to fall back on. Deploying large tests without first working out a test coverage strategy could waste vital resources and delay delivery. Leaning too far in the opposite direction and focusing on the faster unit tests could create test escapes that only surface in end-to-end scenarios. Striking a balance between test methods makes absolute sense and should be a point of focus.

CST438: Week 4 (Week 79)

 I think the most interesting idea is Hyrum's Law. It says, "with a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody." All that to say that documentation and good intentions don't actually protect you. For example, if a hash table happens to iterate in a certain order, someone will eventually depend on that order whether it's promised or not. Then as an API owner, it means you can't reason your way to the conclusion that "nobody depends on this" for an interface. Having a robust CI system and canarying practice in place before touching anything widely used is a must, which ties right into the logic behind the Beyonce Rule. As an API consumer, it means treating undocumented behavior as unstable even when it's convenient. It's just a safer bet.
When you take them together these approaches shift the topic of maintainability from being a matter of following rules correctly to an ongoing negotiation with reality. I've been on both an API producer and consumer and the lesson in the text rings true.

CST438: Week 3 (Week 78)

 One of the best use cases for Git and other version control systems is on projects where multiple developers are working on a shared code base. Most projects solving non-trivial problems require collaboration. Git is a great way to keep code changes in sync with the remote repository as the single source of truth. Developers don't step on each other while working on their respective code changes.

Many years ago, I used a different system called CVS. One of the big improvements that Git has over CVS is that Git allows developers to work on their own local copy of the remote repository. Even if the network is down, an engineer can work on code changes and commit on their local copy then push those changes once network access is restored. This is a big deal for engineers who work while they travel.

One limitation of Git merge is an issue that I came across today. It's a line-for-line, syntax/text based solution. It doesn't understand context. In my case, since my last pull, another developer had changed the API and updated multiple function signatures. The merge worked, but compilation failed. All this to say that developers can't point to a successful merge operation as evidence that the combined code is valid. We still need plan and align our work as a team and make sure to build and test every time we modify the code.

CST438: Week 2 (Week 77)

This week I learned that React is really powerful for building interactive web UIs. It ties state directly to what shows up on screen. Until this class I had only heard about it from web developer content creators on YouTube.

One thing that stood out was how clean hook-based state management is. Using useState to handle name, password, and message meant no canned function calls, imports, and less cut-n-paste code. It's  simple and easy to follow. Then, since state updates are explicit (setName, setPassword, setMessage), the UI always reflects exactly what's going on. So the save/unregister flow wasn't to hard to trace when I was debugging. React Router is does a lot of heavy lifting. useNavigate() made redirecting after unregistering painless. It's a single function call that takes the burden off of the programmer (me).

That said, it has its limitations. I ran some of my code by a co-worker. He pointed out that React by itself doesn't have a built-in way to share state across components. In our case for this this assignment, we're reading and writing straight to sessionStorage inside the component to manage name, customerId, and jwt, which mixes browser storage logic with UI logic. Apparently their are libraries and features to help with this but I don't have the time to study them.

Data fetching could also be better. Every network call (save, unregister) has fetch -> response.ok -> try/catch logic. Looking into it, there's no caching, no request de-duplication, no retries, no built-in loading states (I might be able to implement that part). It's the same in Order.jsx, Login.jsx, and EditOrder.jsx too.

I can see why React is so popular and I why people have found it useful to build on top of it. That explains why there are third party solutions to some of the shortcomings that I pointed out.

CST438: Week 1 (Week 76)

What did I expect that a course in Software Engineering would cover? I figured that it would cover the design, development, validation, and maintenance of software. In other words, it's not just a matter of coding/programming, it builds on what we have learned in other classes and expands on that to cover the entire software life cycle. I also came in with the expectation that we would cover different approaches to software development and why they can make sense in different settings. For example, why might the waterfall model make sense for one organization/project vs the agile model?

I also fully expected that we would do some of our work in teams. It's very rare that you find software that was not developed as part of a collaborative effort. In the workplace, I haven't encountered that scenario. It makes sense that we should try to put that into practice.

Based on the orientation video, the lectures, our first assignments, and the class structure, my expectations were correct.