I’ve been taking on a lot of small projects lately, and have been noticing the same problems over and over. I’ve seen these for years, but I’ve dealt with far more projects in a short time than I ever did in the past.
The checklist below wouldn’t necessarily determine if I’d take a project or not, but would likely influence the rate and schedule.
- Does the current project already have unit tests (or even just an integration test plan) in place? (I don’t expect 100% from anyone, but having *some* in place tells me something)
- Is there any continuous integration in place? Will you (client) balk at me spending time to set it up?
- Is the current codebase even *unit testable*? Most codebases I’ve come across, at least in the PHP and Perl world – are not.
- Is the code portable? I would like to be able to recreate a development environment on a brand new machine in 30-60 minutes with minimal configuration (which should be documented).
- Can I speak with previous team members? Being able to send some emails to ask questions to someone who worked on the project before can save a lot of time. I try to make myself available for code I’ve written in the past as well (to a point – I can’t remember everything!)
- Where is the documentation? Locally written is OK, or on some web-base project system is OK too. On your office whiteboard may even be OK as a start.
- Where are the specs? I fully expect written specs to change, but you’ve got to have some semblance of written specs to start with.
- What sort of project management / project tracking system do you use?
- How available is someone to answer my questions via im/skype/phone/email?
This is likely not a full list, but some of the basics that I’ve seen over and over plague multiple projects. What would be some qualifying questions you’d use in a checklist like this?
I’m setting up phpUnderControl right now, and configuring it with phpUnit, and will need to start a test plan process for a client in the next few days.
Dude, this reads to me like a list of reasons NOT to take on consulting/contracting projects dealing with custom legacy code. In the vast majority of cases, you are not going to find these kinds of things in place. If a company had the foresight, discipline and time to do all of these things, they probably would just hire a full time developer. Consulting gigs where legacy code is involved are usually fraught with peril because of the lack of these very things. I’ve been burned by a few of these projects in the past. Knowing what I know now, I would set a very high rate and low expectations for any such project.
This is sort of my point. One of the things I’ve found is that asking about these issues seems to remind people that you’re not just a ‘code slinger’ and that there’s a lot more to getting the job done. I’m setting some expectations, and the more people don’t have those things in place, the easier it is to justify turning the work down or to justify higher rates.
Nice checklist. The only thing that occurs to me is that the question about whether it’s unit testable is not really necessary. If it has no unit tests, you can be pretty sure you have to refactor it to make it testable.But as you say, just asking helps set expectations.
@Dagfinn – what I’ve done occasionally is ask to see code before I take on something ( I wish I did that *all* the time in the past ). Having a visual inspection will answer that ‘is it testable’ question sometimes right off the bat.