When bad software requirements happen to good people (2011)

https://smartbear.com/blog/when-bad-software-requirements-happen-to-good-peop/

by ohjeez • 5 years ago

47 13 5 years ago

I feel the pain. People here will recall the heyday of Paper Prototyping i think. It sounds silly in the 21stC to even suggest such a low tech step, but it's saved my a$$ in the past.... and given me a solid basis to renegotiate a price if/when the feature-creep begins! Anyone else done similar for a client who doesn't _really_ know what they want? ;)

Terry_Roll• 5 years ago

IF you cant bill for feature creep on a contract get a new lawyer who can write out better contracts or walk away, some things are not worth the hassle.

You can get a contract for bespoke programming which includes such things as feature creep billing for just a few hundred, its not expensive but if its not written down, you dont have much of a leg to stand on if things ever had to go before a judge or some sort of arbitration unit.

If working in a team, there need to be documented standards for everything from the UX to the DB and everything in between. Its just common sense.

hinkley3• 5 years ago

Time and materials works well, until the customer’s boss figures out they’ve been faffing about for a year and have nothing to show for it.

hinkley3• 5 years ago

What always seems to happen is they say, “we want it for this much.” And you say, “that can’t be done… well, it could be done if we can assume all X are Y. Is that okay?” They agree because it means yes. Then a year later they realize that not all X are Y and they start renegotiating, like we’re just arguing about paint colors or bathroom fixtures instead of something foundational, like the footprint or number of floors or what city you built it in (we decided we don’t want to live in Detroit. Can we have it in St Louis instead?).

I have been wondering for a while if we should just never ask those sorts of questions, because they don’t know, we hear what we want to hear, they hear what they want to hear, and nobody has any idea what’s actually going on, and later we won’t look at how we got here.

sam_lowry_2• 5 years ago

All good, but this is written in the blog of Smartbear, the company that sells products that divide engineers and the non-technical crowd.

I heard many times product owners saying that if this can't be done in OpenAPI and shown in SwaggerUI, then it can't exist. Websockets can't exist. Lazy loading, asynchronous communication, HTTP/2... all went south because product features are defined by lads viewing OpenAPI through SwaggerUI.

the_gipsy• 5 years ago

How is that the fault of swaggerui?

sam_lowry_2• 5 years ago

Because the company behind it benefits from ignorance?

some_chap• 5 years ago

So, Agile?

satyrnein• 5 years ago

This is the key:

Feldman also believes strongly that projects stay on track when developers bite off software requirements into as small pieces as possible.

Continuous deployment (for example) surfaces miscommunications pretty quickly, so you don't go too far down the wrong path. (It doesn't help with estimating completion dates, though.)

I just wish feature flags were sightly less annoying to manage.

nenadst• 5 years ago

15 years after Scrum was invented and 10 years after the Agile Manifesto someone writes such an article ?

I agree that knowledge about Agile was not widespread enough in 2011, but this reads like something from the early 90s.

mrweasel• 5 years ago

This might just be me not keeping up with the details, as I pretty much lost all interest in development methodologies after eXtreme Programming 20 years ago. It's all the same, either waterfall or some rehash of the iterative programming models of the 1960es and 1970es. Hell, even waterfall is suppose to have iterative elements, most just skip that part.

Business want Scrum, Agile, whatever, because it allows them to change their mind, but they also want the deadline of waterfall development. Clearly some "pure" form of agile is better, if you care about the quality of the outcome. When you have deadline and fixed budgets, the idea that you don't truly know when you're done rules out anything but waterfall, where all requirements are to be laid out in advance.

Deadlines and budgets are why bad requirements happen. Almost no one is able to write good requirements, it's simply too difficult in all but the most basic cases.

hinkley3• 5 years ago

I’ve heard it said that Scrum only works if you assume half of XP. I don’t have a coherent counter argument to that statement.

Deadlines and budgets are why bad requirements happen. Almost no one is able to write good requirements, it's simply too difficult in all but the most basic cases.

Because projects get cancelled if you tell the truth. Even if there’s an uglier truth that the company is screwed if we don’t finish this project.

One boss referred to this somewhat grotesquely as “getting them pregnant.” Once started, sunk cost fallacy makes them keep dumping more money on it until they get what they need or the pain gets too high. In a lot of ways Agile is a more humane way of getting the same results without the deception. You give them a taste of things to come and keep trickling it out a bit at a time.

quickthrower2• 5 years ago

Long requirements were not a failure by the developer: they are arse cover.

When bad software requirements happen to good people (2011)

Related Stories