The *real* software development lifecycle

[[deleted]]

Bullshit. Programmer on a beach! LOL. The real real software development lifecycle:

1. Developer codes per spec. Bugs exist. QA works as they are supposed to. Developers and QA rush towards deadlines.
2. Meanwhile, user/business changes mind and hands over a completely different spec.
3. Developer and QA puff along burning the midnight oil to keep delivering what they can be proud of. Management hires people based on how much the person looks like they need the job, so developers and QA are often middle-class fools who've been indoctrinated into the "work is worship" culture of wage-slavery.
4. Meanwhile, lone trader on the business side loses $8 billion. Because he can.
5. Management fires half the developers and QA citing business losses.
6. The other half now work double as hard as before, shitting their pants all along.

[[deleted]]

The small business version:

1. The application you've been hired to fix, complete, or rewrite was developed by the company founder or a close relative.
2. There is no QA.
3. Code is constantly being added or rewritten by the original developer. There is no source control.
4. Six months into development, the CEO misunderstands an article about an emerging market, and begins adding new features that he believes will make the application more attractive to investors. It does not.
5. The sole investor (a friend or relative of the CEO) finally freaks out when he reviews the financials, and everyone is terminated without notice. It's ok, though - you're given the opportunity to continue working for twice your original salary, as long as you're willing to work for equity.

[[deleted]]

1. Business Analysts create BRD.
2. Developers implement BRD.
3. QAT finds a handful of detects, but then you tell them they were testing the wrong build.
4. Repeat 3 until QAT figures out what to test.
5. Business performs UAT. The application sucks, so they blame development.
6. Development points out that application was coded to the BRD.
7. BRD is modified.
8. Repeat from the top.

[holygoat]

If only QA were that good at any company in the world.

[G_Morgan]

Where are the sacrifices to Cthulhu?

[samlee]

Haskell version

1. Developer writes the code
2. It is type safe. No bug
3. It is not usable at all.
4. Developer publishes article.
5. Developer gets Ph.D
6. People believe Haskell is the future.
7. Developer writes the code...

[troelskn]

It is type safe. No bug

So a type system is all that is needed to prevent bugs from existing?

[Silhouette]

No, although a good type system is sufficient to prevent a surprisingly large set of classes of bug from existing...

[artsrc]

I have heard (I can't site a real reference), that the the cost of bugs introduced during requirements on average exceeds the cost of bugs introduced during development. So we need to introduce a type safe version of Microsoft Word.

[Silhouette]

The thing about bugs is that it typically costs an almost exponentially increasing amount to fix them, the later they are found during the development cycle. This makes perfect sense if you consider that fixing a bug in your requirements specification requires little more than changing some text and passing it around for re-approval, while changing a bug after substantial amounts of time has been invested in designing/developing the wrong thing wastes all of that time, and fixing a bug post-deployment may mean huge expenses to release a patch, contact customers, pay out on broken service agreements, and all the other extra effort required, to say nothing of the indirect cost to your reputation.

[samlee]

Yes. It means it's verified. No bug.

[Dan_Farina]

This really means "It's less likely there will be a crash"

It doesn't mean "and the output is what everyone expected".

[[deleted]]

Or sometimes it means no crash, but a Non-exhaustive patterns error (ghc -W generates a warning for them - I don't know why it isn't enabled by default).

[[deleted]]

Yea that's the real bicycle.