12

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?

gnat
  • 21,442
  • 29
  • 112
  • 288
dhblah
  • 339
  • 1
  • 3
  • 11
  • 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 Jul 23 '13 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. – Gilbert Le Blanc Jul 23 '13 at 15:18

5 Answers5

17

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.

Honza Brabec
  • 602
  • 4
  • 11
  • +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.".... – Th 00 mÄ s Jul 23 '13 at 11:27
  • 5
    +1 But consider making prototypes as well as / instead of paper specs. – MarkJ Jul 23 '13 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 Jul 23 '13 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 Jul 23 '13 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 Jul 23 '13 at 16:18
  • "Part of a job of a competent software developer is to help those people make up their mind.": Strictly speaking, this is more the task of an analyst. In a structured environment, analysts produce functional specifications that are given to testers and developers. These produce test specification and a running implementation, respectively. The testers then verify the implementation. Of course, in some teams the so-called "developers" are expected to do everything. – Giorgio Jul 23 '13 at 17:34
7

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.

Neil
  • 22,670
  • 45
  • 76
  • 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 Jul 23 '13 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 Jul 23 '13 at 10:21
  • Well, actually, spec will be here, but I'm not sure when it will be. – dhblah Jul 23 '13 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 Jul 23 '13 at 13:22
  • @Telastyn, there is a difference between a pencil sketch on a piece of paper and a full formal specification. I think it is not unreasonable to ask for more information, wouldn't you agree? – Neil Jul 23 '13 at 13:31
  • 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 Jul 23 '13 at 14:08
  • How strict and anal you can be about requirements acceptance depends on the terms of the development contract. If the client's going to hold you liable for failure to meet their acceptance criteria, those criteria must be laid out in precise detail before you agree to work on them (doesn't mean it all has to be done up front, but the client must stay ahead of your velocity). If the client is willing to be more flexible, then part of the story itself, and your work as a dev, is to gather the requirements. I do this all the time as an in-house dev. – KeithS Jul 23 '13 at 15:57
  • @Telastyn What did my answer read? I said that he should ask for more information. If for whatever reason, the client cannot give you more information, I think that's perfectly fine, but I would hold off to commit to doing the project. Otherwise you risk that they throw everything but the kitchen sink that you already agreed you'd do. Maybe the client isn't "correct" to do so, but you wouldn't be correct to accept such a job in my humble opinion. – Neil Jul 24 '13 at 10:00
3

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.
Mahdi
  • 1,983
  • 2
  • 15
  • 25
  • +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 Jul 23 '13 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 Jul 23 '13 at 14:11
1

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.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
1

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.

John R. Strohm
  • 18,043
  • 5
  • 46
  • 56