Setting your rates II

Posted on June 11, 2009

I Meant to post this yesterday and just plain forgot, so I’ll try to get two out today to make up for it.

I got some feed back on my post the other day about setting rates. It’s an interesting topic to a lot of people. One of the questions it did bring up was how to deal with negotiating on rates, or specifically dealing with a customer that doesn’t want to pay what you’re asking.

I for one set out my rate at the start in a quote, explain that it’s competitive and that’s what it costs.

I’m open to negotiation if for example you’re offering me a couple of days a week for a month, few months or a year. It costs less to develop and maintain one relationship like that than the equivalent in smaller customers – even if it is putting more eggs than I may like into one basket.

If on the other hand it’s a couple of days then I’m going to be much more firm about my rates.

One strategy for getting paid what you should, and giving a customer a price they want is to determine the budget from the outset then structure a proposal around that. Once you’ve got a number, make sure you can deliver what they want, or negotiate on a cut down version, which you can deliver within their budget. If it’s design work, cut some of the revisions, base the design on a template of their choosing. For coding work cut some of the scope, remove one or two of the lest important requirements.

A lot of times you may just find “you’re too expensive” really means, “we can’t afford it” and there are a lot of great companies out there that aren’t just being cheap, even if that’s the way it may seem on the surface and they’d be more than willing to compromise on the scope to get it done properly within their budget. Then who knows, revisit the rest in a few months time.

Other times you just can’t meet in the middle, you can’t do the work in the time allowed by the budget but don’t give up – there might still be a deal you can both cut. Maybe they offer a service you’re currently paying for, or have staff that aren’t being fully utilised you can borrow. Trading your services for theirs isn’t a bad thing, you still get a client, word of mouth referrals, case studies, testimonials and add to your portfolio and you still get something in return for it. I’ve done this in the past and it’s always worked out well for me, in fact it’s probably lead to more work from and through that client than we could otherwise expect.

If all else fails, my advice is to walk away. It’s hard but the brutal truth is that you’re risking getting stuck in a working relationship where the other side doesn’t value your skills. In my experience that attitude extends right through into how they value your opinions and the result of your labours. To them what you produce is a commodity and they’re probably going for the cheapest quote they can find. Everyone has worked with people like this, it’s not fun and it’s almost never worth the money. In fact, my advice is run – don’t walk.

Related articles by Zemanta

• Happy Customers Equal Better Business (underthegrapetree.blogspot.com)
• 5 Ways to Please Your Clients and 5 Reasons Why You Should (sitepoint.com)

Is it better?

Posted on September 29, 2008

After reading this post what Jamie said hit me as well:

This is when I realized how trained I was in the processes at my former workplaces. This email would have been delayed until it was perfect[...] After fixing this there would be another thing and then another thing. A 2-day project would drag on for a week of redesign, approval, and development[...] It’s one thing to read Getting Real [...] It’s another thing to actually practice the principles. [...] That part is trickier than you think.

I don’t think it’s just Jamie and I don’t think it’s just his former workplaces. We’re all trained to make excuses not to launch, it’s endemic in the culture of most organisations. We endlessly pay lip service to the principals of release early and release often, agreeing in principal
with the principals – but put very little of them into practice.

A manager’s role is to facilitate an organisation’s march towards better – all too often it’s a weak manager that needs constant input on projects and at the root it’s fear of inadequacy on their part that builds a culture of ass covering. It’s obvious that at 37 Signals they don’t suffer from being crippled organisationally when executive decisions need to be made but executives are absent. Their staff are trusted to make decisions and they’re empowered to release better features.

When your last change was ready to deploy, when it was better than what was there, did you release it? If not, how long did it take you to get from that point to actually releasing it and how many people had to give final approval?

Why not empower your staff with a simple test – Is it better than what we have? No flow charts, no organisational hierarchy; just a simple question.

Never rewrite your software

Posted on July 1, 2008

All software is a work in progress none is ever perfect. It will always have bugs, sometimes it might even seem that the software is nothing but bugs an it’s in these dark times when we normally say fuck it, let’s start over. Not always, some of the good excuses I hear for a rewrite are:

• New blood Someone new comes along and the first thing they suggest is a complete rewrite – It’s alarming the number of times I hear this suggested. Sometimes it’s contractors, which is somewhat exusable – it’s more billable time for them. Other times it’s by people newly in charge or new to the team.

• Team members have left – rightly or wrongly they’ve been blamed for the code, and coding them out seems like a good idea

• Too many bugs – An effort to hammer out the bugs feels like it would take longer than to rewrite from the ground up

• New tools! – A shiny new framework is out and you want to use it, it will solve all your problems and put all your spare cycles to work sorting out poverty and war.

Common to all the above is the fact that everything seems like it would be easier if only you could get out from under the crushing weight of legacy. And it’s a very attractive fallacy; Bugs could be solved by reworking the architecture; Features would be easier if only the code wasn’t written that way; That new framework would fix the bugs we’re seeing because of the one we’re using.

resist the temptation

They sound like good reasons, but that’s the problem with attractive things that are bad for us – they’re attractive. It’s so much easier to believe that the grass would be greener if we re-turfed the lawn than to work out how to fix those brown patches.

it almost always takes longer than you expect

A complete from the ground up rewrite will take longer than you think. It will probably take almost as long as it took you to get where you are now. It’s tempting to believe that you don’t need planning meetings to work out what has to be done. It’s right there a spec in the current implantation, just get started! So you’re initial estimate is just a stab in the dark anyway.

Add to this the further false belief that since you implemented the features once already, you’ll be able to do it faster this time around. You won’t, well you might – but you won’t implement them as optimistically quick as you think you will.

Throughout the process you’ll also be further from a releasable product than you think you are – much further. In a rewrite you have to rewrite every feature all those “all we have left in component x to do is…” bullet points add up.

All of this leads to one last problem with timescales for rewrites – in order to get anyone else to buy into them they have to be wildly optimistic about the schedule. So just when you need everyone most motivated and excited, as you’re gearing up for a release, you’ve set them up to be demoralised by missing an increasing number of deadlines.

you’re reinventing the [buggy] wheel

Programmers are people, people are creatures of habit. You’ll inevitably end up implementing part of your radical new system in a very similar way to your existing system. Then you’ll be forced to make the same compromises as you’ve made before and you’ll undoubtedly introduce some bug that’s already been patched in your existing software.

Some of your old code will also be good code, at best you might cut and paste it into the new code base but for the most part though trying to hammer it into place and wire it up is going to be as long and as buggy a process as rewriting it. So instead you follow the rewrite it all logic and rewrite it all.

you’re standing still

When you’re rewriting your software you’re stainding still in almost every way possible. If you’re rewriting everything, you’re spending an awful amount of time not moving your application or business forward. Personally and professionally you’re not learning much new (unless a new framework is your excuse).

Even if you’re squeezing some features into your rewrite, probably because it’s been so long since a release you’d be lynched by a mob if you refused, it’s so long before the users are actually going to see them that you might as well not be. The perception of your software isn’t going to be sometimes shaky, but getting better all the time – it’s going to that it’s buggy and the bugs are never fixed.

you’ll probably end up no better off

The sad and somewhat painful truth is if a team can’t fix something – getting them to make a new one is probably not going to fare much better. Your new version is probably going to be no better than the old, will certainly be worse than an itteratively developed and incrementally improved version of what you had could have accomplished in the same time.

Also problems you’re having with a framework or tool probably aren’t going to be magically solved by using a new one. Most of the these arguments are born out of a naive belief that because the framework isn’t doing what the developer is expecting, the framework has bugs, changing frameworks should then solve the bugs. The problem is of course developer expectation versus reality and more often than not due to some underlying misunderstanding of the platform the framework or tool is abstracting – a reality that a new framework cannot change.

how to sensibly go about a whole rewrite of your software

While it’s not sensible to start a full rewrite of your software, it’s also ludicrous to decide that nothing written should be changed. Software development is a process not an event. If it’s not working fix it; if it’s complicated and bug prone, refactor it; if it’s shit, code it out. Just don’t throw the good out with the bad.

Start where it hurts

In the case of bug riddled software start with an area that is causing the most trouble. Patch the big bugs first. It can be a painful process, I won’t lie. It’s demoralising to everyone to have buggy software and it’s not exciting or glamorous to fix it.

Bug fixes are one of the most thankless tasks developers are asked to perform, so make sure you break it up with some of more challenging and interesting tasks, throw a few features into each iteration.

if I could do it all over I’d change…

These are the generally the things that are hurting the developers rather than the user. Some of them are far reaching, architectural or framework choices. They can all be fixed though, and you don’t need to rewrite the whole application to get there.

Again, start with the ones that hurt the most, if it’s part of the architecture refactor it. If it’s a framework you’d like to integrate to solve problems, try it out on part of the code and work to roll it out incrementally.

I promise it will be quicker, a lot quicker to go down the incremental route than it will be to rewrite the whole thing in one go.