Slashdot Mirror
Why Your Software Project Is Failing
An anonymous reader writes: At OSCON this year, Red Hat's Tom Callaway gave a talk entitled "This is Why You Fail: The Avoidable Mistakes Open Source Projects STILL Make." In 2009, Callaway was starting to work on the Chromium project—and to say it wasn't a pleasant experience was the biggest understatement Callaway made in his talk. Callaway said he likes challenges, but he felt buried by the project, and reached a point where he thought he should just quit his work. (Callaway said it's important to note that Chromium's code is not bad code; it's just a lot of code and a lot of code that Google didn't write.) This was making Callaway really frustrated, and people wanted to know what was upsetting him. Callaway wanted to be able to better explain his frustration, so he crafted this list which he called his "Points of Fail."
"he should jut quite his work"
not a lot, just a little
If we're going to talk about Callaway's Points of Fail, and create a link in the Slashdot summary that *looks* like it takes you to that list, then perhaps there should actually be a link to the list.
Callaway's original Points of Fail blog post.
You know, instead of the usual Slashdot way of pointing to an article wrapper that talks briefly about some of the points and then eventually links to the real list.
~Idarubicin
As a software dev for closed source, our problems are creeping into open source at an alarming rate. Standups, Kanban, Scrum, swim lanes, and other political middle management bullshit is making it harder and harder to as theo de raadt once said, "shut up and hack."
The other issue is runaway devs. Gnome and KDE turned into piss pots almost overnight because they followed lockstep with whatever was trending. gnome grew hotspots that were clickable and draggable in an attempt to appeal to tablets, and KDE's widget framework turned into a swirling vortex of lights and colours that chewed through ram like none other. And the "fuck it lets move on" mentality has got to stop. Pottering epitomizes the swinging dick Linus so rightly kicked after his team was called out for set it and forget it code that ultimately broke more things and didnt play nice.
bottom line: dont lose focus in stability and function.
Good people go to bed earlier.
What depresses me bout software is how often we JUST DO NOT LEARN! Yes I am shouting. I am frustrated by the situation. Software development seems to be riddled with arrogant know nothings who think they can cut corners or reinvent the wheel because doing the right way isn't "7337".
Software Development is not an Engineering discipline by any means, at best it is a craft, because the hard lessons are not explicitly taught to newbies who are not evaluated on how well they follow those practices and tests them on them as part of a core knowledge base. Which is how real Engineering disciplines do it.
putting the 'B' in LGBTQ+
Google developers do not understand how to design APIs.
Wrong. Wrong. Wrong! Google developers get paid buttloads of money, more than you or I could hope to make. These are the elites, the 1% of the 1%.
Because they are so highly paid the problem cannot lie with them since we are repeatedly told if you pay developers what they're worth you will get excellent results. Just like paying CEOs of companies who go running to Uncle Sam to protect them from their own incompetence.
The problem must lie elsewhere. Look harder.
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
People start projects because they want to create something cool, not because they want to be project managers. But if they don't manage the project it fails.
Clearly you don't understand engineering. Engineering isn't just "model your entire design". Engineering is decomposing your problem into problems that are "spec-able". For example, build your bridge out of steel and bolts. You don't have a model of bolts in your design, you have a spec for bolts that you use in your design that is testable (performance and tolerance) and then you use parts hierarchically in your design. The bolt is designed separately and is made out of some alloy that has specs and is tested (performance and tolerance)...
The problem with most software isn't that it can't be modelling and rely on basic physical principles, it's that many projects fail to take specs and testing seriously, and the specs that exist don't address performance and tolerance (aka, error handling). If software did this, things would be more engineered.
Right now many software artifacts are similar to the prehistoric bridges that cross chasms in jungles in third world countries. They work, people cross them every day, but things were made empirically so nobody knows what might cause them to fail, so it's hard to rely on them.
It's not that bridges that were built 100 years ago were "better", but they were actually built to specs and of course survive to this day (which can't be said for the prehistorical variety). However, improved bridges are continually desired so we use better parts and build even better bridges today because modeling allows us to get tighter specs on the parts that make up bridges and the stresses that we are putting on those parts.
But doing all that requires better engineering discipline not dismissing it as a something that isn't applicable. Engineering is an useful approximation of the physics (an approximation which always gets improved over time), not a practice of physics.