How to approach the ol' "this will just be a small application"? Yeah right?

Question

Ok I have run into this many times, but here is the worse case scenario slightly exaggerated.

A client says "hey can you make us this small module to do this small task"?
Me: "Sure no problem".

So based on budgets and constraints etc., I skip some of the architecting and dive right in and make it no sweat.

Then they ask for another module. And another. And some enhancements. And this all happens very slowly mind you, over years. And before you know it, you have this monster application that is horribly architected.

What do you do when you are asked to do something small? You don't know if it will keep growing...if the client will keep asking for additions (and neither do they).

You can't over-architect the thing, because it's just a small application after all, and they will go somewhere else if you say (in that I know all voice) "Well just in case, let's architect this thing into layers with top-o-the-line security and separation of concerns. In fact let's go with a dependency injection tool that will really make this thing fantastic blah blah blah".

They will say "yeah right" and go to someone else.

Budget, time, and perception are as important as architecting the application itself.

How should this be approached?

I guess the question really boils down to "When you don't have all the information for the final outcome of what appears to be a small application, how do you avoid (or mitigate) making architecural and design decisions early on that will be completely innapropriate later?

Answer 1

I've run into quite a few of these and what I normally do is exactly what you did, dive right in and get it done.

When they come back for more, it means that their business model is working and that they should be willing to invest a little more. That's when I sit them down (typically 3rd module depending on complexity) and tell them the bad news.

I will lay everything on the table, offer to redo the entire thing including the latest module and tell him how much it will cost. They will typically have some sticker shock at the start but if you have a good working relationship and your stuff works, it shouldn't be a huge issue.

Make sure that they understand three things though:

1. If they really don't want to bother with a complete rewrite, you will still do the 3rd module. It might take you a few more hours and you will bill them for it. Remind them that they should really think about doing a rewrite in the future, cos the longer they wait, the more it will cost.

2. It's really is gonna cost them more to get someone else to do it. The new person has to redesign everything with minimal understanding of their needs and quirks, which means extra rewriting time and the risk that he won't do as good a job.

3. That you are not trying to make a quick buck. The thing DOES need a re-design.

BTW, if your billing habit is something like half now, half when its done, you might consider offering them extended payment terms. Change it to half now and split the balance over the period that you will be working on it. That might lessen the pinch if they have budget issues.

Answer 2

Just make him a small app and get paid for it.

In my experience it is compelling to invest more time at the beginning than really needed, just in case the customer wants more. But you have to weight the efford in doing it (do you get paid for it) vs. the propability that all these additional changes really will occur. The whole app might be replaced completely after a year.

And by investing time in the initial architecture, you might feel that you do yourself a favor. But really, you just do the customer a favor by making the other modules cheaper for him.

Just bill your customer a bit more for each successing module and refactor the initial project step by step, but always just to match the customer needs.

Answer 3

Previous answers are good and, if I'm honest, what I would probably do. That said, I'm slightly uneasy at this approach in that you are making decisions that properly belong to the customer, based on an assumption of what they want (and the desire to land the job)

I can't help feeling one should do is be be honest with the customer and give them the choice: 1. I can do this quickly and (relatively) cheaply now. It'll be great - it'll work - but future enhancements will cost incrementally a little more 2. I can spend more time on it up-front, which will cost a little more and not add any real benefit for the users, BUT it will save you money in the long run if you need to add new features.

Ideally, you'll be able to give them some ball-park figures of time/costs - otherwise the conversation could be too academic - but I appreciate that arriving at these numbers can also take effort. At least, framing the discussion in terms of previous projects would make life easier for the customer (and making the customer's life easier should be a top priority :-))

Comments others have made about having a good working relationship are spot on - but you can begin that process by being honest yourself. If the customer is the sort that you can't even have that conversation with, now might be the time to ask yourself how much you need this job...

Answer 4

I would treat each of these "iterations" as a separate project. You should close out these projects when each little module or addition is done. Then when they want something else, draft the paperwork. And as time goes on, the software becomes more expensive...which means you're charging more for each small project.

It's one way to look at it, instead of one...LONGGGGGG project.

Answer 5

how do you avoid (or mitigate) making architecural and design decisions early on that will be completely innapropriate later?

You can't. Programmers aren't psychics. While we can predict simple things or see UI improvements, we can't really code beyond what we don't know the client might want later (do you see the insanity there?).

Your question mentioned that it had business processes but I'm not sure if they are good processes. Here's some pointers:

• Require all changes and additions signed in writing and with a budget.
  • Because you have bills to pay
  • The writing and signed part make sure it's what they really want and cuts back on 90% of the frivileous things that clients change their minds on half-way during the project

Your Overgrown Product

It happens to all of us. Rebuilding from scratch usually is a terrible idea, especially considering it will be done again in the future.

Instead, I'd contract for the changes that the user asked for. Add extra time for each feature, using the original time to work on the feature, and the extra time to improve the overall architecture, one small improvement at a time. The goal isn't to completely "fix" the architecture in one contract, but instead to slowly chip at it over time.

Slowly improve the code iteration by iteration, focusing on the parts that really matter.