5 ms·

I was on a 12-person failed project, the kind of which you owe millions to the govt. We had a problem with the search, we couldn’t get performance. I told my b

I was on a 12-person failed project, the kind of which you owe millions to the govt. We had a problem with the search, we couldn’t get performance. I told my boss: “See, they wrote ‘The old search responded in 2 seconds. The new search must take at least the same time.’ We could almost add a sleep(2000) before starting the search.” He went with it. They dealt to drop the requirement on the performance of the search on a “mutual agreement.”

lostcolony 5y ago
Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.
- toomuchtodo 5y ago
  Requirements are hard in dysfunctional organizations, or those with more stakeholders than capability and agility.
  - lostcolony 5y ago
    Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.
    - sharken 5y ago
      Also, how long will it take to build and how much will it cost? :) This is where Agile ought to improve things, but then SAFE came along and we were back to square one.
    - kenniskrag 5y ago
      but there are some architectual significant requirements, which have to be known upfront.
      - lostcolony 5y ago
        I both agree and disagree with you. There are requirements that will affect architecture that, if they're guessed at and turn out to be wrong, will lead to massive refactoring and/or large amounts of effort being thrown out. 100%. Where I disagree from most businesses is in the implicit belief they have that seems to be "better for devs to be idle than for devs to work on code that will be thrown away". I'd rather take a guess and start work; best case we're right and are ahead; worst case we're wrong and have learned some useful lessons. Which you'll note is the same dilemma as every other decision related to the project, with the only difference being the scope.
  - sokoloff 5y ago
    I wonder the extent to which those two specifications describe the exact same organizations.
- quasit1 5y ago
  I've worked in such places. The reason it is that way is because you will receive a broken description/specification/story of what you are supposed to implement. You have a choice to make when that happens, you either implement it as specified or you reject it because it is broken. The problem is that if you do reject it then it will take about 6 months to get back a specification that is broken in another way and then you have to make the same choice... So after a few iterations you just say "fuck it" and implement it as specified and then hope that you get a chance to fix it before shipping it (or that it doesn't become your headache later on...).
  - mattchamb 5y ago
    Enterprise developer here. Exactly this. If you reject the spec, you won't get another one before the deadline that was committed before you got the spec you want to reject.
    - rsuelzer 5y ago
      Instead of implementing the obvious intention of the spec and waiting to see if anyone complains?
      - lostcolony 5y ago
        The intention usually isn't obvious. The stakeholders have spent so much time documenting, in depth, the solution that they want, while spending no real time documenting or communicating the specifics intricacies of the -problem-. That's the issue in a nutshell; Checkbox Driven Development implies "if we just define the solution well enough upfront, we'll get what we need!" instead of "if we define the problem well enough, and let dev pitch us solutions, and iterate as we go, we'll get what we need". Which implies that the devs are not to be trusted to come up with a solution themselves. To deviate from expectations and be congratulated, you have to, A. Be certain you're doing the right thing, and B. Have an audience that can recognize you did the right thing. Both of those require a level of trust that is just missing in this sort of org.
- chromanoid 5y ago
  "Monkey Paw Development" was a new one for me :) Thank you! Great analogy. Reminds me of this :D https://www.youtube.com/watch?v=cDA3_5982h8 https://www.youtube.com/watch?v=cDA3_5982h8
  - lostcolony 5y ago
    Yeah, I just coined it while making the post. :P Less a "also (currently) known as" and more of a "also (should be) known as". Certainly how I'll be referring to it in cynical moments from here on out.
  - SumBird 5y ago
    I was reminded of this: https://www.youtube.com/watch?v=5W_wd9Qf0IE https://www.youtube.com/watch?v=5W_wd9Qf0IE
mPReDiToR 5y ago
Don't ever go to https://i.reddit.com/r/maliciouscompliance https://i.reddit.com/r/maliciouscompliance You only have so many hours in your day. Way back when, we used to remind people to be careful what they wished for in case they got it.

lostcolony 5y ago

Ah yes. Checkbox Driven Development. AKA Monkey Paw Development, where you give exactly what was asked for; it remains surprisingly popular in the government and enterprise spaces.

toomuchtodo 5y ago
Requirements are hard in dysfunctional organizations, or those with more stakeholders than capability and agility.
- lostcolony 5y ago
  Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.
  - sharken 5y ago
    Also, how long will it take to build and how much will it cost? :) This is where Agile ought to improve things, but then SAFE came along and we were back to square one.
  - kenniskrag 5y ago
    but there are some architectual significant requirements, which have to be known upfront.
    - lostcolony 5y ago
      I both agree and disagree with you. There are requirements that will affect architecture that, if they're guessed at and turn out to be wrong, will lead to massive refactoring and/or large amounts of effort being thrown out. 100%. Where I disagree from most businesses is in the implicit belief they have that seems to be "better for devs to be idle than for devs to work on code that will be thrown away". I'd rather take a guess and start work; best case we're right and are ahead; worst case we're wrong and have learned some useful lessons. Which you'll note is the same dilemma as every other decision related to the project, with the only difference being the scope.
- sokoloff 5y ago
  I wonder the extent to which those two specifications describe the exact same organizations.
quasit1 5y ago
I've worked in such places. The reason it is that way is because you will receive a broken description/specification/story of what you are supposed to implement. You have a choice to make when that happens, you either implement it as specified or you reject it because it is broken. The problem is that if you do reject it then it will take about 6 months to get back a specification that is broken in another way and then you have to make the same choice... So after a few iterations you just say "fuck it" and implement it as specified and then hope that you get a chance to fix it before shipping it (or that it doesn't become your headache later on...).
- mattchamb 5y ago
  Enterprise developer here. Exactly this. If you reject the spec, you won't get another one before the deadline that was committed before you got the spec you want to reject.
  - rsuelzer 5y ago
    Instead of implementing the obvious intention of the spec and waiting to see if anyone complains?
    - lostcolony 5y ago
      The intention usually isn't obvious. The stakeholders have spent so much time documenting, in depth, the solution that they want, while spending no real time documenting or communicating the specifics intricacies of the -problem-. That's the issue in a nutshell; Checkbox Driven Development implies "if we just define the solution well enough upfront, we'll get what we need!" instead of "if we define the problem well enough, and let dev pitch us solutions, and iterate as we go, we'll get what we need". Which implies that the devs are not to be trusted to come up with a solution themselves. To deviate from expectations and be congratulated, you have to, A. Be certain you're doing the right thing, and B. Have an audience that can recognize you did the right thing. Both of those require a level of trust that is just missing in this sort of org.
chromanoid 5y ago
"Monkey Paw Development" was a new one for me :) Thank you! Great analogy. Reminds me of this :D https://www.youtube.com/watch?v=cDA3_5982h8 https://www.youtube.com/watch?v=cDA3_5982h8
- lostcolony 5y ago
  Yeah, I just coined it while making the post. :P Less a "also (currently) known as" and more of a "also (should be) known as". Certainly how I'll be referring to it in cynical moments from here on out.
- SumBird 5y ago
  I was reminded of this: https://www.youtube.com/watch?v=5W_wd9Qf0IE https://www.youtube.com/watch?v=5W_wd9Qf0IE

mPReDiToR 5y ago

Don't ever go to https://i.reddit.com/r/maliciouscompliance https://i.reddit.com/r/maliciouscompliance You only have so many hours in your day. Way back when, we used to remind people to be careful what they wished for in case they got it.