John McAfee would be spinning like a rotisserie chicken in his grave. Or at least he would be if McAfee Software hadn’t already turned to shit long before his death.
So the temp files are still identified, but anybody smart enough to figure out the code is also likely smart enough to know that calling the developer will not help get rid of the file.
Don’t underestimate the stupidity of your average person.
Have reviewed 16 year old code for a very well known company in the last week with this exact comment peppered throughout, alongside delightfully helpful comments like:
// do not delete or change this it just works
// TODO temporary fix added 12/09/11 to fix incident must be removed ASAP
// CAUTION this returns false here instead of true like it normally does, not sure why
// if true then matched to valid account not is true
What a time it must’ve been, being able to publish your phone number online without fear. Now you give it to any website and it’s sold straight away to advertisers. Making it public would be a nightmare.
I have my phone number on my personal website—never had any adverse consequences. In fact, the only two calls I’ve gotten have both been at my work number which isn’t on there somehow. One to ask a genuine question and one to give me 30 bucks in appreciation.
You don’t even need to make public yourself. City governments do it automatically, mostly if you’re a home owner. Other companies do it because they keep getting hacked.
Try it.
Go to your favorite search engine and type in your phone number (format it to look like a phone number). If you haven’t already gone through and had yourself removed from these types of sites, you’ll be appalled at what you find.
How bad programmers comment their code. Good programmers don’t comment at all and let the code speak for itself, leaving commenting to some obscure and arcane implementation the coder left in after a week long binge on caffeine and gummy bears.
I was rewriting some old code of mine and ended up stripping out the comments. I kept reading them instead of the code, which I had been changing, and they were irrelevant. (I added new comments back in, though a big reason to rewrite was to make the code more self-explanatory.)
Code should absolutely speak for itself. But the occasional comment is still good to explain the ‘why’ of the code when the why isn’t very obvious, often due to a niche requirement. Also any time you have to break out a hack, that needs comments up the ass, what was the bug, what URL did you find the fix at, why does this hack work, etc etc. It’s very satisfying to go back and remove those hacks after they are no longer needed, often because the underlying technology fixed the bug that had to be hacked around.
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.
Did you read all the way to the end of the article? I did.
At the very bottom of the piece, I found that the author had already expressed what I wanted to say quite well:
In my humble opinion, here’s the key takeaway: just write your own fucking constructors! You see all that nonsense? Almost completely avoidable if you had just written your own fucking constructors. Don’t let the compiler figure it out for you. You’re the one in control here.
The joke here isn’t C++. The joke is people who expect C++ to be as warm, fuzzy, and forgiving as JavaScript.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.