What to ask first
Oh my. Here’s a Project That Sucks. It sucks so much I seriously don’t (yet) know how to make it not suck. How crazy is that?
Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.
The client is on board with my famous Disclosure Agreement, so I can give a lot of details, but I don’t feel like identifying them too closely. I’ll just say it’s kind of a matchup site for third-party transactions in a niche vertical market. It matches buyers and sellers of highly specific machine parts.
There’s been a single developer on this website for five years now. It’s PHP4 or maybe PHP5. I think they said it’s maybe 120,000 lines of code or so.
It’s a membership business model. You don’t pay for listings or transactions. You just pay a monthly membership fee. Considering the value this thing will deliver, and the size of the realistic potential market for membership, I don’t think the client is crazy to think there is substantial profit potential here.
The site is technically online and operational now. By that I mean that there are a few members, who are not yet required to pay the membership fee because it’s all kind of pre-pre-beta.
It’s just that so many things on the site either don’t work at all, or work in really clunky ways. Some of the dropdowns don’t, the search function kind of works some of the time, and the pagination seems to do a SELECT * every time you click Next.
I don’t know. This could be an absolute nightmare to fix. It looks like a nightmare of Technical Debt. Maybe not. Hard to say.
Here are some of the things I want to ask first when I hang with the developer:
- Where’s your version control repository? (I’m afraid I know the answer to this.)
- How do you unit test? (I’m sure he doesn’t in the sense of actual TDD, but is there any repeatable process at all?)
- Is there a backup you can “build” and run from?
- How do you know when a feature is done?
- How do you know when a feature is requested?
- Can we describe this project in terms of Minimum Marketable Features?
- Who is doing acceptance testing?
- …and how?
- I don’t suppose you have anyone besides me to review code with?
This may become another not-quite-Agile project. Maybe the right answer is to pair with this guy for a while to fill in skills gaps and create a rhythm of progress, set up a KanBan to regulate the feature flow, and work with the actual customer to nail down a very specific set of Minimum Marketable Features.
Also, I’d be really shocked if they have version control. That’s got to happen before anything else!
Business-wise, who knows? There may not be funding to do this right, or even to do it wrong.
Among the Eight Reasons Why Software Projects Suck, I bet we’ll hit about six. I’ll let you know how it goes.