Ask HN contractors: do you charge to write a spec? | Hacker News Reader

Ask HN contractors: do you charge to write a spec?

10 pointsdrewcrawford7 comments

I've been involved in the contracting market for the last couple of years. Lately I've seen a big uptick in large (100+ hour) projects with bad or nonexistent specs that want pricing information. 3-page "outline" specs, specs with ridiculous requirements obviously written by clients (100% uptime), etc. There's grey area too--I often see specs that need a 25% or 50% rewrite, or need a few features reworked to be feasible.

I'm concerned that writing the spec needed to eventually determine the pricing information is a bad ROI vs, say, writing actual code with my time instead, working on paying projects, etc. At the same time, nontechnical clients don't always understand why they need a spec, or don't understand why the spec they have is bad, or why I can't determine pricing information from it, and usually the trust isn't there at that early stage of the pre-relationship to convince them.

What do others in the contracting market do in this situation? Do you just invest the 10-20 hours in speccing all the projects, do you tell them to come back with a spec, do you offer to do it hourly? How does that conversation usually go? Where do you draw the line between free and paid work?

Form my experience after 6 years of contracting (web applications, Ruby (before: Perl, PHP, Java) in Europe): no customer (small to int. enterprise customers) had something that would qualify as a spec. Nobody was interested in having specs upfront. Just start coding/talking and bill by the hour.

Of course the lack of spec ends in frustration, bugs and unachieved deadlines/features but it seems every customer wanted it that way and has budget reserves for that. This is brilliant for contractors that just do 9-5 coding and very, very bad for passionate folks that are usually lurking/participating here on HN :-(

that's why i lose faith in the IT industry: We have the tools for agile planning, prototyping, mockups to make it good.

But only a fraction of the companies is really doing it and most stick to their hold habbits and just want a contractor "to do his job"

I could not have put that better if i'd written it myself. I notice you mentioned Europe, it may just be a European thing I'm here too, although most of my clients, and in some cases bosses have been stateside corporations.

You mentioned also that vital steps are missed out. I've seen powerpoint slides taken to be "the detailed design", and very good detailed functional and technical specifications completely ignored, and in some cases laughed out of the room.

I think there is a misunderstanding about IT in general, and this is it: most businesses are in the IT business whether they like it/understand it, or not. The IT function is of critical importance in every business today, but it's not represented at the top, the same way an accountant or legal function is. Yet we all know how you can look at a record in a database and tell what a person actually did, we just fail to communicate that power well enough.

I have to say that our industry has a bad reputation for not being able to communicate well, and that is probably it's biggest problem.

I've seen this within two big US companies as well (one known then as a big online bookstore, the other one a search company gone horribly wrong - you can imagine.). But to be fair, I dealt most of the time with their european subsidiaries.

I also think that failing business start to fail in the top management level and one level below. It's kind of the "bozo explosion" that Guy Kawasaki describes. If you put one Bozo-Manager into the CTO-position everything will break down:

People just want to present something that looks important, not deliver something that delivers real value to the company. They don't want to spend time to specify a product and take risk, they just delegate it to some poor (external) guys that waste some money.

If they succeed, it was the great manager with his superior skills. If not, the developers sucked, hire some other next time.

Ah...btw.... "Evangelist"/Advisor to the CEO-guys....

One very recent example of a large private media company in Germany: They have a couple of technolgy evangelists reporting to the Owner of the company. They have a very strong personal relationship over tens of years but are just incompetent in all IT matters. They just repeat the current buzzwords ("it must be key/value and loosely coupled!" because Google and Amazon does it.). The problem is: That's true but it's not what the company needs to achieve the project goals. If you have no users, why do you want to scale from the beginning? It's an iterative process, also: premature optimization is the root of all evil.

As most of the media companies/publisheres are private companies (or at least the mayority is still owned by the founding families) they have no external pressure to fix their broken strategies/HR/management.

They can keep losing money in their current business for another 10-15 years until they have to shut down large parts. So they still try to get away with crappy IT products.

Another story:

Internet Explorer 6 is still quite common in the enterprise area in Germany. Why? Because SAP sold crappy technology. They build a big part of the user interface on top of the proprietary MS IE6 platform. Also the customers have very long purchase cycles. Upgrading ERP-software is done every 10 years or so as it's so expensive...

I often say, If we would operate nuclear power plants this way, we would have a Cernobyl/Fukushima-Event per week...

I've been contracting for +10 years and also get paid for writing specs. But I don't believe in having specs and fix-price contracts. Either you as the contracter will be spending more time than planned, or you will be driving your customer nuts by discussing one change request after the other.

Agile/Iterative approaches are the way to go for me and writing the spec is part this..

One interesting approach I remember from a previous thread on this topic, was to charge for writing a spec, but discount it from the project total if the client decided to go with you.

That said, if the spec is large enough where you're going to be investing a significant amount of time into it, I don't see why it should be any less billable than the other work you do.

It's in contractor's best interest to do the spec himself as it's the only way to get all the important details right. Do charge for the spec, but credit the amount back if they decide to proceed with the project. This is a very common practice.

I made my living for years writing specs :)

Reply on news.ycombinator.com