[HN Gopher] When bad software requirements happen to good people...
___________________________________________________________________
When bad software requirements happen to good people (2011)
Author : ohjeez
Score : 46 points
Date : 2021-12-11 22:35 UTC (1 days ago)
(HTM) web link (smartbear.com)
(TXT) w3m dump (smartbear.com)
| sam_lowry_ wrote:
| 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 wrote:
| How is that the fault of swaggerui?
| sam_lowry_ wrote:
| Because the company behind it benefits from ignorance?
| greypowerOz wrote:
| 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 wrote:
| 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.
| some_chap wrote:
| So, Agile?
| satyrnein wrote:
| 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 wrote:
| 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 wrote:
| 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.
| quickthrower2 wrote:
| Long requirements were not a failure by the developer: they are
| arse cover.
___________________________________________________________________
(page generated 2021-12-12 23:01 UTC)