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."
This is /. Having horrific "editors" is to be expected. I wonder what it pays to click accept on a story every hour or so.
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+
He has a bunch more further down too, including "requiring support for Microsoft Visual anything". Which is 100 points of fail.
If you ask me, not having support for Microsoft Visual anything is however 2,000 points of fail, and not being compilable on Windows at all without using some cross-compiler/Cygwin/MinGW is 5,000 points of fail.
Unfortunately that includes everything made by GNU.
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.
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.