Waterfall method: talk about building a rocket for 5 years, build the rocket, rocket needs to be totally redesigned because we forgot to put a place for people to go - massive change reqeust, build new version. Project Delay: 27 years
Agile Method: a rocket is not software - do not use Agile
Kanban - kanban is agile
Scrum - scrum . . is also Agile. What are you doing, go back and do the waterfall one
Your comparison is interesting, but let’s consider some historical facts. The Apollo program, which successfully put humans on the moon, actually employed many principles we now associate with Agile methodologies.
Contrary to popular belief, it wasn’t a straightforward Waterfall process. NASA used frequent feedback (akin to daily Scrums), self-organizing teams, stable interfaces so that teams are an independent path to production, and iterative development cycles - core Agile practices. In fact, Mariana Mazzucato’s book Mission Economy provides fascinating insights into how the moon landing project incorporated elements remarkably similar to modern Agile approaches. Furthermore, here’s a NASA article detailing how Agile practices are used to send a rover to the moon: ntrs.nasa.gov/api/citations/…/20160006387.pdf?att…
While it’s true that building rockets isn’t identical to software development, the underlying principles of flexibility, collaboration, and rapid iteration proved crucial to the missions’ success. Programs like the Apollo program adapted constantly to new challenges, much like Agile teams do today.
Regarding Kanban and Scrum, you’re right that they fall under the Agile umbrella. However, each offers unique tools that can be valuable in different contexts, even outside of software.
Perhaps instead of dismissing Agile outright for hardware projects, we could explore how its principles might be adapted to improve complex engineering endeavors. After all, if it helped us reach the moon and, decades later, send rovers to it, it might have more applications than we initially assume.
Also, Kanban was invented in the 40s as a process for automotive production lines. That’s why it aligns so well with maintenance and operations projects in IT. It’s ridiculous how more and more people claim it comes from software development and would not fit hardware projects, when that’s the core use case of the methodology.
Good points all - I was just responding to a comic strip that I think meant to riff on the old, “what the customer wanted”, “how sales described it”, “what engineering proposed” etc. about project management but it just wasn’t finding the funny as it put the onus on Agile like isn’t this a silly discipline - well, no. :)
Agile methodology is a defined framework for software development success. It helps teams adapt and solve specific needs at a given time and prioritizes accelerated time to market and the value of user insights. Agile is based upon a set of four values and twelve principles laid out in the Manifesto for Agile Software development.
See, the thing with that is it’s just really aspirational. Anything could be Agile if you do it in the right spirit, if the manifesto is the whole thing.
Edit: I suppose what I should have asked is: “Is Agile really a system, or just a philosophy?”
It’s both. The word “Agile” is used for either depending on context.
To that end, it’s several “systems” depending on if it’s used for straight-software development in a department, or manufacturing with technological components, or an entire enterprise using Agile concepts (like SAFe). Each one could be slightly different, and each one is some variation on the philosophy.
What it differs from mostly is a phase-gate approach typified by project management, where a plan is made, a budget secured, and a timeline set. All of those things are of course present in Agile, just in different ways and not one-after-the-other.
The big difference is project management has been around forever; Agile just over twenty years. So the former is what everybody knows by default, the latter sounds very “woo woo” to a lot of people. I think that’s really what the comic is trying to say - Agile stuff sounds silly.
Agile is indeed more of a mindset than a rigid system. In my recent experience helping a tabletop game team, we applied Agile principles to great effect. Rather than trying to perfect every aspect of the game at once, we focused on rapidly iterating the core mechanics based on player feedback. This allowed us to validate the fundamental concept quickly before investing time in peripheral elements like the looks of the game.
This approach embodies the Agile value of ‘working product over comprehensive documentation’ - or in our case, ‘playable game over polished components’. By prioritizing what matters most to players right now, we’re able to learn and adapt much more efficiently.
Agile thinking helps us stay flexible and responsive, whether we’re developing software or board games. It’s about delivering value incrementally and being ready to pivot based on real-world feedback.
In my experience, you can’t expect it to deliver great working code, but it can always point you in the right direction.
There were some situations in which I just had no idea on how to do something, and it pointed me to the right library. The code itself was flawed, but with this information, I could use the library documentation and get it to work.
ChatGPT has been spot on for my DDLs. I was working on a personal project and was feeling really lazy about setting up a postgres schema. I said I wanted a postgres DDL and just described the application in detail and it responded with pretty much what I would have done (maybe better) with perfect relationships between tables and solid naming conventions with very little work for me to do on it. I love it for more boilerplate stuff or sorta like you said just getting me going. Super complicated code usually doesn’t work perfectly but I always use it for my DDLs now and similar now.
The real problem is when people don’t realize something is wrong and then get frustrated by the bugs. Though I guess that’s a great learning opportunity on its own.
Principle developer tip: rewrite history to make yourself seem smarter.
Soft reset the whole branch and commit a series of atomic and semantic patches (eg separating code, test, and refactor changes) that tell a clean narrative of the changeset to reviewers, future blamers.
Sometimes I’m in awe at the effort people put into these memes. Well done 😄
P.S Now make one about people who squash 100 commits into one without cleaning up the message and have a single commit with 1k added / 2k removed in it for the sake of “clean” history.
Yesssss, so true. Anytime people say they want history to be “clean” I insist they explain what they mean because more often than not they’re going to suggest something that makes the history way less useful.
Also the strip stops midway through as Waterfall was an invented thing just for a paper. And during your UP work you actually had the customer put in that input and hence it was like in this cartoon strip.
Code is the most in depth spec one can provide. Maybe someday we’ll be able to iterate just by verbally communicating and saying “no like this”, but it doesn’t seem like we’re quite there yet. But also, will that be productive?
Plan to go to orbit, blow up seconds into the flight, and declare it a success.
Plan to refuel in orbit, make it minutes before the rocket brakes. Fire the FTS, it fails, the rocket blows up a minute later und declare it a successful test of the FTS.
Argue to NASA that you are not the limiting factor to the moon mission planed for the end of the year, despite delivering none of the milestones.
Tbh it actually sounds a lot more like Boeing these days. F9/F9H is bulletproof reliable these days, and starship is making HUGE developmental strides, while Boeing is still failing to discover and iron out system integration bugs and hardware faults years after they had “completed the project”.
I take it you missed the recent fourth integrated flight test, in which the ship soft landed on the ocean near Australia as planned and the booster soft landed on the ocean near the launch site as planned
Their failure in that flight was expected. They hoped thermal tiles sealing the hinge for the aerodynamic surfaces would seal those against plasma during reentry. They didn’t. Had they, it would have been much cheaper than sealing those more thoroughly. The ship landed regardless of that failure
Disliking Musk is fair, but SpaceX is doing good stuff
I call that following the same successful recipe that got us the Falcon 9.
The mindset that considers those tests failures is the same one that would still be in bureaucracy hell determining what 40 year old technology we should repurpose to get a future over budget, late, and under performing solution designed and built.
AI coding in a nutshell. It makes the easy stuff easier and the hard stuff harder by leading you down thirty incorrect paths before you toss it and figure it out yourself.
So what it’s really like is only having to do half the work?
If it’s automating the interesting problem solving side of things and leaving just debugging code that one isn’t familiar with, I really don’t see value to humanity in such use cases. That’s really just making debugging more time consuming and removing the majority of fulfilling work in development (in ways that are likely harder to maintain and may be subject to future legal action for license violations). Better to let it do things that it actually does well and keep engaged programmers.
People who rely on this shit don’t know how to debug anything. They just copy some code, without fully understanding the library or the APIs or the semantics, and then they expect someone else to debug it for them.
We do a lot of real-time control software, and just yesterday we were taking about how the newer folks are really good at using available tools and libraries, but they have less understanding of what’s happening underneath and they have problems when those tools don’t/can’t do what we need.
I see the same thing with our newer folks. (And some older folks too.) and management seems to encourage it. Scary scary stuff. Because when something goes wrong there’s only a couple of people who can really figure it out. If I get hit by a bus or laid off, that’s going to be a big problem for them.
Gen AI is best used with languages that you don't use that much. I might need a python script once a year or once every 6 months. Yeah I learned it ages ago, but don't have much need to keep up on it. Still remember all the concepts so I can take the time to describe to the AI what I need step by step and verify each iteration. This way if it does make a mistake at some point that it can't get itself out of, you've at least got a script complete to that point.
Exactly. I can’t remember syntax for all the languages that I have used over the last 40 years, but AI can get me started with a pretty good start and it takes hours off of the review of code books.
I actually disagree. I feel it’s best to use for languages you’re good with, because it tends to introduce very subtle bugs which can be very difficult to debug, and code which looks accurate about isn’t. If you’re not totally familiar with the language, it can be even harder
I test all scripts as I generate them. I also generate them function by function and test. If I'm not getting the expected output it's easy to catch that. I'm not doing super complicated stuff, but for the few I've had to do, it's worked very well. Just because I don't remember perfect syntax because I use it a couple of times a year doesn't mean I won't catch bugs.
It’s a picture of the people who submit zero value comment spelling fixes to the Linux kernel so they can claim “I’ve submitted X patches to the Linux kernel” for KPIs or resume building
“Hey Bob, you’ve worked on the Linux kernel before, can you handle this CPU scheduler problem we’re having? Shouldn’t take you too long. We need it done before lunch”
Hey man, I once had an engineering exec (who didn’t last very long) who decided engineers would be stack ranked by SLOC. You can imagine how easy that metric was to cheese, and you can also imagine exactly how that policy turned out.
Give an engineer a stupid metric to meet, and they’ll find a stupid way to meet it for you, if only out of malicious compliance.
I’d have a field day with that. Max line length 70 or 75, excessively verbose function and variable names, triple the normal amount of comments, extra whitespace wherever possible, tab width 8, etc. The possibilities are endless for that metric.
This goes for most LLM things. The time it takes to get the word calculator to write a letter would have been easily used to just write the damn letter.
Its doing pretty well when its doing a few words at a time under supervision. Also it does it better than newbies.
Now if only those people below newbies, those who don’t even bother to learn, didn’t hope to use it to underpay average professionals… And if it wasn’t trained on copyrighted data. And didn’t take up already limited resources like power and water.
This is what it is called a programming language, it only exists to be able to tell the machine what to do in an unambiguous (in contrast to natural language) way.
This reminds me of a colleague who was always ranting that our code was not documented well enough. He did not understand that documenting code in easily understandable sentences for everybody would fill whole books and that a normal person would not be able to keep the code path in his mental stack while reading page after page. Then he wanted at least the shortest possible summary of the code, which of course is the code itself.
The guy basically did not want to read the code to understand the logic behind. When I took an hour and literally read the code for him and explained what I was reading including the well placed comments here and there everything was clear.
AI is like this in my opinion. Some guys waste hours to generate code they can’t debug for days because they don’t understand what they read, while it would take maybe two hours to think and a day to implement and test to get the job done.
I don’t like this trend. It’s like the people that can’t read docs or texts anymore. They need some random person making a 43 minute YouTube video to write code they don’t understand. Taking shortcuts in life usually never goes well in the long run. You have to learn and refine your skills each and every day to be and stay competent.
AI is a tool in our toolbox. You can use it to be more productive. And that’s it.
I think there might be a lot of value in describing it to an AI, though. It takes a fair bit of clarity of thought to get something resembling what you actually want. You could use a junior or rubber duck instead, but the rubber duck doesn’t make stupid assumptions to demonstrate gaps in your thought process, and a junior takes too long and gets demoralized when you have to constantly revise their instructions and iterate over their work.
Like the output might be garbage, but it might really help you write those stories.
When I’m struggling with a problem it helps me to explain it to my dog. It’s great for me to hear it out loud and if he’s paying attention, I’ve got a needlessly learned dog!
I haven’t been interested in AI enough to try writing code with it, but using it as an interactive rubber ducky is a very compelling use case. I might give that a shot.
I have a bad habit of jumping into programming without a solid plan which results in lots of rewrites and wasted time. Funnily enough, describing to an AI how I want the code to work forces me to lay out a basic plan and get my thoughts in order which helps me make the final product immensely easier.
This doesn’t require AI, it just gave me an excuse to do it as a solo actor. I should really do it for more problems because I can wrap my head better thinking in human readable terms rather than thinking about what programming method to use.
programmer_humor
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.