5 ms·

This blog post is true. Developers do fall in to those categories. However, this blog post assumes that developers have been given adequate specifications! Bu

This blog post is true. Developers do fall in to those categories. However, this blog post assumes that developers have been given adequate specifications! Businesses are terrible at defining their requirements; especially large complex businesses. People in businesses don't want to write specs because they're worried about being blamed for them being incorrect. So it's a constant "hot potato" situation.

DharmaPolice 5y ago
>People in businesses don't want to write specs because they're worried about being blamed for them being incorrect. I don't think it's just that - almost everyone (in my experience) finds writing specs especially boring work. With other boring work you just find someone who really likes it and pay them enough to do it for everyone (thus accountants, auditors, health & safety managers, etc). But the spec really needs to be done by someone who knows a particular domain well to have any real worth. So you can't easily farm it out.
- dalbasal 5y ago
  It isn't just boring. It's much worse. Taking any kind of responsibility for a spec is a fools mission. In most shops, doing specs is not highly regarded work. You don't earn much respect or career progression. You will inevitably make mistakes and have failures that make you look foolish and incompetent. You will get blame for this, and other stuff besides. Your successes will be the invisible non existence of a problem no one expected. There will be no praise, no raise. This is true for technical and non technical "owners" of a spec. A spec might be the most important and expensive thing a department head is up to. Most determinant of department success. They will absolutely not proceed without a liability shield between them and responsibility for the spec. Heads-I-Win-Tails-You-Lose is just an extreme condition on the spectrum of mismatched odds in organisational world. The place where successes are overcompensated and failures undercompensated is the smart place to be. Only fools go on fools missions. More realistically, someone is hired for the gig. They maintain a strict CYA trail, documenting who asked for what using which system... and blame/responsibility is dispersed into the system. At this point, it's boring.
  - dgb23 5y ago
    Sounds like something a software architect/designer should do or anyone who gives specific orders in a hierarchical organization. There is always a spec. Either explicitly written down or scattered among emails, tickets and other ad-hoc communication. You can't escape it. Those who decide to do or let other people do have the responsibility anyways.
    - dalbasal 5y ago
      Shoulds are ethereal. >> You can't escape it. Au contraire :) Escape from it is evident, it's clearly a hot potato. No one who should do the job would. Martyrs don't persist.
  - mason55 5y ago
    Yeah, occasionally a process gets designed that looks like "random people who have no real incentive to do a good job put together a spec and send it to me for review/sign off." And the expectation is that it's just a quick once-over on my part so "can it be turned around some time this week?" I always explain that in this kind of process, all the responsibility falls on me. If they write something that's incorrect and I miss it, it's never that the spec writer should have known better, it's that I reviewed and signed off on it. Which is fine, that's part of my role, but if that's the responsibility I'm taking on then the spec review is going to be scheduled as a real deliverable with real time attached to it and if you need it ASAP then you can pick something else to de-prioritize. A good one is "we spent 6 months working with the customer to build this spec, now we're short on time, can you review this week?" Well, if it's so complex that it took 6 months to build why do you think it can be reviewed in a week? It's this idea that spec review is just a quick review but the reviewer is then responsible for anything that's wrong with it that causes a lot of issues in my world.
    - dalbasal 5y ago
      My condolences.
      - 5y ago
dalbasal 5y ago
>> People in businesses don't want to write specs because they're worried about being blamed for them being incorrect True, crucial point. This also explains a lot of developer behaviour. Specs are kind of like legal agreements. You can shake hands on a deal, and that works as long as things don't get adversarial. If things are adversarial, highly specified contracts are what you need. What you can achieve with one isn't like what you can achieve with another.

DharmaPolice 5y ago

>People in businesses don't want to write specs because they're worried about being blamed for them being incorrect. I don't think it's just that - almost everyone (in my experience) finds writing specs especially boring work. With other boring work you just find someone who really likes it and pay them enough to do it for everyone (thus accountants, auditors, health & safety managers, etc). But the spec really needs to be done by someone who knows a particular domain well to have any real worth. So you can't easily farm it out.

dalbasal 5y ago
It isn't just boring. It's much worse. Taking any kind of responsibility for a spec is a fools mission. In most shops, doing specs is not highly regarded work. You don't earn much respect or career progression. You will inevitably make mistakes and have failures that make you look foolish and incompetent. You will get blame for this, and other stuff besides. Your successes will be the invisible non existence of a problem no one expected. There will be no praise, no raise. This is true for technical and non technical "owners" of a spec. A spec might be the most important and expensive thing a department head is up to. Most determinant of department success. They will absolutely not proceed without a liability shield between them and responsibility for the spec. Heads-I-Win-Tails-You-Lose is just an extreme condition on the spectrum of mismatched odds in organisational world. The place where successes are overcompensated and failures undercompensated is the smart place to be. Only fools go on fools missions. More realistically, someone is hired for the gig. They maintain a strict CYA trail, documenting who asked for what using which system... and blame/responsibility is dispersed into the system. At this point, it's boring.
- dgb23 5y ago
  Sounds like something a software architect/designer should do or anyone who gives specific orders in a hierarchical organization. There is always a spec. Either explicitly written down or scattered among emails, tickets and other ad-hoc communication. You can't escape it. Those who decide to do or let other people do have the responsibility anyways.
  - dalbasal 5y ago
    Shoulds are ethereal. >> You can't escape it. Au contraire :) Escape from it is evident, it's clearly a hot potato. No one who should do the job would. Martyrs don't persist.
- mason55 5y ago
  Yeah, occasionally a process gets designed that looks like "random people who have no real incentive to do a good job put together a spec and send it to me for review/sign off." And the expectation is that it's just a quick once-over on my part so "can it be turned around some time this week?" I always explain that in this kind of process, all the responsibility falls on me. If they write something that's incorrect and I miss it, it's never that the spec writer should have known better, it's that I reviewed and signed off on it. Which is fine, that's part of my role, but if that's the responsibility I'm taking on then the spec review is going to be scheduled as a real deliverable with real time attached to it and if you need it ASAP then you can pick something else to de-prioritize. A good one is "we spent 6 months working with the customer to build this spec, now we're short on time, can you review this week?" Well, if it's so complex that it took 6 months to build why do you think it can be reviewed in a week? It's this idea that spec review is just a quick review but the reviewer is then responsible for anything that's wrong with it that causes a lot of issues in my world.
  - dalbasal 5y ago
    My condolences.
    - 5y ago

dalbasal 5y ago

>> People in businesses don't want to write specs because they're worried about being blamed for them being incorrect True, crucial point. This also explains a lot of developer behaviour. Specs are kind of like legal agreements. You can shake hands on a deal, and that works as long as things don't get adversarial. If things are adversarial, highly specified contracts are what you need. What you can achieve with one isn't like what you can achieve with another.