How do you know if you’re software project is going to crash and burn? Use these handy tips. Consider it a reverse Joel Test.
- It started out with Waterfall and then once they completely derailed and went into a free-fall, started calling it “Agile-ish”. This is also known as fake agile, or “fragile”.
- Fixing a bug always exposes another bug. If the software is so buggy that you cannot even GET to certain parts of it due to the bugs, then fixing one just exposes another one, and another one, and another one. This is not the same as causing a bug with your bug fixes, although that’s not good either.
- One or more of the central technologies became unsupported by the manufacturer before the project even started. Even better if the technology line has been discontinued entirely.
- You’re using PowerBuilder or any other “rapid development tool” that abstracts away actual code in favor or checkboxes and drop-downs. Libraries, toolkits and APIs are all fine. These tools are like playing Twister with code.
- The technical lead cannot correctly use his email client or browser. If someone cannot even use basic, standard software, how can he properly lead a team of programmers?
- The Project Manager is writing code and a developer is managing the schedule. Seen more often than I’d care to admit.
- There are more business or domain people on a team than actual technical folk. 1 programmer with high turnover + large code base + critical system + huge bug list = no problem?
- There is a test suite from a previous programmer but half of the tests are failing or don’t compile. For extra fun, check if reported bugs would have been prevented if the test suite had been used.
- The process for adding a single line of code requires multiple lines of commentary. A comment at the line stating the reason and your name. A comment at the top of the file putting your name and update date. A per-file commit with descriptive message. Update to the bug-tracking/PM software. Etc, etc.
- The phrase “it’s not a bug, it’s a feature” applies to most of the “features” in the product. “The system wasn’t designed for that.”
Have any other signs from the trenches?
#2 I’ve seen more than I care. Nothing worse than attempting to fix a bug, and getting caught in a landslide of errors and bugs along the way.
You are using some automated “out of the box” code test instead of writing actual test fixtures or cases. You also have to pass the rigorous but irrelevant tests of this product 100%.
You are 90% feature complete and holding. Every time you add 1%, marketing or some other things changes a different 1%
You have 9 man-months more of work, but they want it in 30 days so they just hired 8 temps (can’t 9 women have 1 baby in 1 month?).
HR, Legal, the accounting department or something else external prevent you from getting and keeping critical people on from the start until the project is finished so you are forced to deal with turnover.
The complex pieces which were going to be coded by the most experienced (and thus expensive) people have been outsourced somewhere 8 or more time-zones away. To the lowest bidder. Your only contact person has a thick accent and no technical knowledge but will scribble down translated versions of your questions and relay answers the next day.
You have to use Outlook, Lotus Notes, or whatever because that is what corporate uses. Including the anti-virus software that isn’t even detecting a virus you can see on TaskManager.
(#2) Refactoring will take too much time so is against the rules – better 1Kloc of crap than 100 lines of clear elegant and bug free code.
You hired a company which went 4 months past the deadline, charged double, and your project went through 3 different “Project Manager”’s? That’s always my favorite.
@tz. LOL! I’ve seent hat 3rd one one your list happening on a project I worked on. It took up twice as much time after adding the extra people.
Code in production is newer than code in the version control
What is strange is long ago when I began my career, there was this already classic book.
Wikipedia has a nice summary under “The Mythical Man Month”, published in 1975.
Amazing that nothing changes. Even when the questions have been answered, the way shown back when they were punching Hollerith cards with FORTRAN and COBOL.
I do disagree with a few things (e.g. irreducible number of errors – true only if you don’t refactor and it is an alarm that you need to refactor the code or redesign to fix what is causing the interactions and complexity).
And some things have been widely adopted. The problem is that even good ideas often turn into a liturgy or ritual to be performed – ends in themselves to placate the gods of coding forturne – instead of means to the end of allowing good code to be written.
Rarely is code pure mathematics where you are implementing a well known equation for a clear purpose where bad data cannot occur. It is a creative act – more like architecture in which the building must stand up even in bad weather, but also be functional, and there isn’t just one way to do it. It is something like Jazz – all the music fits and sometimes surprises, but there is no way to specify more than a theme for inspiration.
The second bit of ancient (in internet time) wisdom was DeMarco and Lister’s “PeopleWare” about managing creative teams.
Factories only have economies of scale because they produce identical or nearly identical parts. That doesn’t work since software is never identical, though I can personally estimate fairly accurately from a complete spec where I can get a good insight into the complexity. But resolving it is never doing the same thing twice.
So much of that list, reminds me of what being the webmaster was like. The only positive things that I can say, is it had one hell of a security system plugged into it as saving grace, and working on the code, makes programming front panels look fun.
# When team shares that dev huddles (dev meetings) are a waste of time.
# When major team decisions are made by people outside the team with little context. And you get to know them from outside sources.
# When every technical decision is approved by manager.
# When developers haven’t spoken to customers in months.
Some of the things from my experience..
When you can’t screen who you hire and have to work with whoever is hired for you due to company process.
When you have to take the company’s word that the new hire really is as experienced as the resume says, again b/c you aren’t part of the interview process.
When it takes 2 months to remove a person due to red tape b/c he/she doesn’t live up to his skills.
When it takes an additional 2 months to replace a person due to the red tape.
When that project is expected to be delivered within 8 months.
Just a few of my gripes…
[...] 10 Signs Your Software Project is Going Down From the comments: “Code in production is newer than code in the version control” [...]