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
His list, instead of the link to a blog with an article about the list. That blog post is interesting - though the picture of the author scratching is just weird. Was that taken at a lice convention?
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+
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.
And not just software. Look at security as well. And so many other computer-related areas.
For me it's more like ... someone "learned" one way of handing it when s/he was working ALONE.
Then that person never learned that the practices need to be changed when you are part of a TEAM.
And releasing your code to the public is being part of a team.
In the real world you can learn but you are most often prevented from putting the learning into practice. After 30 years programming, I still spend 95% of my time dealing with other people's code and "maintenance". The opportunity to do things the right way usually was passed years before I joined.
Actually real engineering disciplines screw up too and for some of the same reasons as software. Quick and dirty hacks in hardware driven by unrealistic deadlines from upper management, last minute bandaids applied because it's too expensive to redesign, confusing document control, lack of knowledge transfer if someone leaves the team, etc.
Also remember that the list is about open source software. Some of the things that are wrong there aren't wrong with proprietary software or internal tools, distributed teams have different requirements from teams that are all in the same aisle (ie, open source is greatly improved if there's a web based source code control browser, but that loses importance if everyone on the team already has a license of a the source code control system's GUI tool).
Open Source also means lots of college students or recent grads, full of excitement to get stuff done but without the real world experience to know how to go about it; and full of hobbyists who start off strong then slow down and stop; etc. For example, hobbyist has only a home PC with Windows, and for budget/time reasons does not want to bother with portability to hundreds of different types of systems; or the hobbyist is the sort who thinks Microsoft Visual Something is a really good state of the art tool and bases the entire project on that.