I recently was assigned to a task, but it says only a couple of words, like, do it as it made there, with no actual spec attached. What is the best thing to do in that circumstances?

  • I think the OP should elaborate a bit more on the context. The approach depends on if the client is an end-user or someone from inside the development team (project manager, technical leader, etc.).
    – Andris
    Commented Jul 23, 2013 at 14:58
  • 1
    If you want some practice, you can attempt to answer questions on Programmers. Most questions require the answers to draw information from the questioners. Commented Jul 23, 2013 at 15:18

5 Answers 5


Your situation is quite common and when I was developing things for non-technical clients it happened to me all the time.

When those people hire you they most often don't know what they really want. They just know they want "something like that" or "something that can help me with this".

Part of a job of a competent software developer is to help those people make up their mind. That means that maybe you should think about the project and come with some specs yourself. Then you can finalize them with the other side. The specs are essential because with them you can clearly say if you completed the task or not.

  • +1 for creating some viable specs and discussing these with the client. Not in a technical way though. More like "this will enable you to do X, but X1 will note be possible.".... Commented Jul 23, 2013 at 11:27
  • 5
    +1 But consider making prototypes as well as / instead of paper specs.
    – MarkJ
    Commented Jul 23, 2013 at 11:37
  • If you had to push forward in some fashion, this would be the best solution, but you risk that the client doesn't like what you come up with just the same and there is a high potential for losing time. I wouldn't work without some basic specifications.
    – Neil
    Commented Jul 23, 2013 at 12:46
  • +1. As software devs, we're all expected to be one part computer scientist, one part computer engineer, one part business analyst, one part software architect, and a few more parts, all just to get the daily job done.
    – KeithS
    Commented Jul 23, 2013 at 15:53
  • I agree with you, but I don't feel very confident to propose my specs, mock-ups to client. Because there are other devs with higher authority that will throw away my solution after I made it. =/ Even when client is happy with it.
    – dhblah
    Commented Jul 23, 2013 at 16:18

Get the specifications! If that is not possible, reject the task! It is your responsibility as a programmer to force the person asking you to do this job to provide you with sufficient information. This is not only in your best interest but also in the best interest of said person. Otherwise you risk that your client will be unhappy of the results, and as a consequence, that will make you downright miserable.

  • 3
    Customers are notorious for not knowing what they want. That's why the agile processes exist. Many companies work years without ever having detailed specification of anything in advance.
    – Jan Hudec
    Commented Jul 23, 2013 at 10:19
  • @JanHudec, true, but agile process requires that the specifications come later. Sooner or later the specifications must come. It sounds to me that not even agile process can help this fellow.
    – Neil
    Commented Jul 23, 2013 at 10:21
  • Well, actually, spec will be here, but I'm not sure when it will be.
    – dhblah
    Commented Jul 23, 2013 at 10:30
  • 3
    @Neil - Full, formal specifications are in most cases overkill. Worse than overkill, they actively impede work and the collaboration needed to create software that satisfies both technical and business needs.
    – Telastyn
    Commented Jul 23, 2013 at 13:22
  • 1
    @Neil - There's a difference between asking for more information and rejecting the task wholesale. Task requirements like "make a table X that looks like Y and contains Z info" (what I gathered from the OP) are certainly sufficient to work against.
    – Telastyn
    Commented Jul 23, 2013 at 14:08

Well, your question seems a little bit vague to me because you really didn't mention what you need to know and what you get from the client, however, I always try to be realistic and think like the client in these situations.

Let say you have money and you want to order a sport car, or a big house or the nicest leather jacket in the planet or whatever else you think it's nice to buy. The question is, when you're ordering something that you're not expert in that field, can you specify the materials, specifications, etc. or not? For example, if you have to choose the gate for your big house, will you specify where they have to place the lock and the keyhole size or you just simply leave it up to them and you will choose the shape of the gate and its color? Again, if you're not an engineer, can you specify all the characteristics and specifications of the car you're gonna order or not?

Simply you can't specify them because you don't have any idea what they are and how they should be. As a client/buyer, you just need to draw the outlines of the final product and it's their job to make it work in a way that fits your needs.

Imagine if you feel your client needs some level of extra security for their web application, or if they mention that clearly, then it is your job to offer them to use SSL. You don't need to make them understand what is SSL, how it works and why it's necessary for them. You have to tell them what is the added benefit of using that thing (in this case SSL), the extra effort needed to implement it and its price, and then it will take up 30 seconds for them to make up their mind and decide whether they want it or not.

However, I agree that in some working situations you might probably receive vague tasks, mostly from your supervisor or the project manager. The only thing I can recommend in these situations is:

  1. First, make them clearly understand that they didn't provide sufficient information (make it official, send them email so you can referrer to that in the future).
  2. Second, ask for the information you need in a nice way, let them knows that you will work better if they give you the proper information or at least as much as they have/know (make it clear that it's for their benefit, not because you are lazy or unexperienced).
  3. If the information is not provided or it's not sufficient in the end, try to do it as normal and as usual as possible. Try to understand them and their needs. If you didn't specify your preferences on the light colors for your new house, you probably want warm or pure white (something usual) not anything red-ish/blue-ish.
  • +1 for the lighter touch. Sometimes lack of spec is the result of a lot of hotheaded ignorance, but often us engineers need to understand that viewing a problem at its logical base level is difficult for a lot of people. I think that's why technical writers get paid so much.
    – Katana314
    Commented Jul 23, 2013 at 13:44
  • @Katana314 I wish if there was p++ for programming people, so we could talk to them and debug them like computers ... the problem is that most of the time we don't know how to talk, understand and deal with non-programmers and that's why many projects fail not technical difficulties.
    – Mahdi
    Commented Jul 23, 2013 at 14:11

It depends on how much your process is flexible.

If your process is agile, you can start prototyping it and get various aspects either approved or clarified along the way. It is what agile process was created for. But it requires that somebody (customer delegate, product manager or such) is available to approve it and that you won't be blamed for delays caused by them changing their mind over and over.

If your process is not agile, responsible person to approve the realization is not readily available or you risk being blamed for delays, you have to insist on getting the specification clarified before you accept the task.


If your employer/supervisor/client didn't give you a specification, you will have to write one yourself and get them to sign off on it.

For every project, there are three things you need to know:

  1. What is the problem you are trying to solve?
  2. What are the deliverables?
  3. How will you know when you are finished?

Until and unless you have the answers to these three questions, WRITTEN DOWN AND SIGNED OFF, you are not ready to start doing ANYTHING but getting the answers to these three questions, written down and signed off.

The answers to these three questions form the core of your spec and your statement-of-work.


Not the answer you're looking for? Browse other questions tagged or ask your own question.