Posted by Ben Simo
A couple weeks back, there was some discussion on the software-testing group about the use of the term "SDLC" on resumes. (Matt Heusser posted some excerpts from this conversation here.) My warning flags go up when people claim to have a "full understanding" of the SDLC. I sometimes see this as an indication that someone may not be as experienced as they claim. The "SDLC" will vary from one company to another and even one project to another. SDLC is a process documentation term -- and there are many differing processes used to develop software. Its not how people talk in the real world.
I recently re-stumbled upon a description of the SDLC that seems to be fairly common across many companies and projects. Perhaps this is what people are referring to when they claim full knowledge of the SDLC. :)
Software doesn’t just appear on the shelves by magic. That program shrink-wrapped inside the box along with the indecipherable manual and 12-paragraph disclaimer notice actually came to you by way of an elaborate path, through the most rigid quality control on the planet. Here, shared for the first time with the general public, are the inside details of the program development cycle.
- Programmer produces code he believes is bug-free.
- Product is tested. 20 bugs are found.
- Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
- Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
- See 3.
- See 4.
- See 5.
- See 6.
- See 7.
- See 8.
- Due to marketing pressure and an extremely pre-mature product announcement based on over-optimistic programming schedule, the product is released.
- Users find 137 new bugs.
- Original programmer, having cashed his royalty check, is nowhere to be found.
- Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
- Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
- Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
- New CEO is brought in by board of directors. He hires programmer to redo program from scratch.
- Programmer produces code he believes is bug-free.
Even the above demonstrates some naivete.
Bugs are not necessarily the fault of a developer. Many bugs are defects in the requirements and design; not the code of any specific developer.
Developers rarely get royalty checks or bonuses.
I've never known of a "testing department" serving a single "developer". Now that's quite some tester to developer ratio.
Perhaps "SDLC" is just a term we use to model something that is really complex.
4 Comments:
June 25, 2007-
Chris Loosley wrote:
-
-
June 25, 2007
-
Chris Loosley wrote:
-
-
June 25, 2007
-
Ben Simo wrote:
-
-
June 25, 2007
-
Ben Simo wrote:
-
-
Maybe the person who claimed to know all about SDLC was an ex-IBMer, like me. I remember that those networking specialists were pretty well trained on SNA :)
On a more serious note, we're always learning new lessons, so no expert would ever claim to have complete knowledge of their field. So anyone making that claim must be particularly ignorant.
It's OK not to know what you don't know, but only a truly ignorant person does not know that there are things they don't know.
Imagine a resume claiming "a full understanding of" performance, programming, Web 2.0, or management! If I were hiring, it would go straight into the circular file.
When I was testing communications protocol implementations, I used to be be able to speak HDLC and SLIP. I never was able to understand the details of the FEC algorithms. However, I did understand that putting the FEC in software on top of SLIP or HDLC was less effective than putting it in a hardware device below the software link layer. :)
It's OK not to know what you don't know, but only a truly ignorant person does not know that there are things they don't know.
Exactly the reason my warning flags go up when someone claims to know all there is about something. That something is either very simple or the person is particularly ignorant.
There is always more to be learned.
Post a Comment