5 ms·

As a software engineer, this document annoys me. I don't know if it's how it's intended, but it feels like a bunch of nosy document-writers pointing down at so

by efaref 12y ago

As a software engineer, this document annoys me. I don't know if it's how it's intended, but it feels like a bunch of nosy document-writers pointing down at software engineers saying "you're all shit, and we're going to tell you why". First, I reject the premise that software is poor quality when compared to other engineering disciplines. Software is immensely more complicated than any other field of engineering ever imagined. The space shuttle, commonly referred to as the most complex machine ever built, has around 2.5 million parts. The Linux kernel alone has over 16 million source lines of code. It's an order of magnitude more complex than the SPACE SHUTTLE!. And even given that difference in complexity, disasters and problems occur still in the physical engineering world. I think the reason why people have a perception that software is bad, is because, perversely, most of the time, it's really good. It's so magical that I can, with a device in my pocket, call up the latest sporting results for a game happening on the other side of the planet with only a few seconds delay, and perhaps even see video footage of it happening - all this enabled, it should be clear, by millions and millions of lines of software - that I can't even conceive of all the things that went right to get that far if the youtube app crashes for some unforeseen reason. The magic stopped, ergo software is crap. The document then goes on to attempt to define a process for developing software. What is lists is a bit laughable: 1. Planning: Produce a plan to do the work. 2. Development: Perform the work. a. Define the requirements (see 4.2.2) b. Design the program c. Review the design and fix all defects d. Code the program e. Review the code and fix all defects f. Build or compile and fix all defects g. Test the program and fix all defects 3. Postmortem. Anyone who's ever done software development, will tell you that the order for these is something like: 2b, 2a, 2b, 2d, 2c, oh - someone's asking for sizings, better do some 1 - 2d, 2c, 2d, 2b, 2a, 2d... Trying to develop software in a process-oriented fashion is doomed to failure, because developing software is the act of creating processes for a computer to execute. If it were possible to define a software development process, we could get someone to write it up in C, or Python, or whatever, and then just kick back and let the computer do the development for us! Heck, if we take the extra time to code in PV and EV calculations, it'll have a working progress bar too! [|||||||||||||__________] Coding... (50%) That being said, these elements of the "process" are useful as a taxonomy for the kinds of activities that must be performed as part of software development, and if you fail to do any of them, you will likely produce inferior quality software. But listing them in a regimented fashion, or trying to follow them as a "process", simply does not work. But in the end there's an awful lot of waffle in what amounts to a pretty impenetrable document. There's got to be a better way to codify what we actually do when we develop good software. Not what we think we do, or wish we did, or claim we do to sound impressive. Edit: grammar.

diego 12y ago
PSP was not designed for consumer apps. It was conceived for mission-critical software that needs to be right the first time, such as the Space Shuttle's (400K LOC). I took a class on PSP at CMU in the 90s and it was obvious that I'd never use it at any of the companies I was interviewing with at the time. Your comment sounds to me as if a dentist said "look at this jackhammer, what a useless tool. I'll never put this inside anyone's mouth."
- 0xdeadbeefbabe 12y ago
  This is an insult to jackhammers.
- HeyLaughingBoy 12y ago
  You'd be surprised. Having (been forced to) used PSP for the last 4-5 years, I'm not such a huge fan of it, but a surprisingly large number of companies building consumer software are adopting PSP/TSP.
mdaniel 12y ago
I have two small corollaries to your description. The first is that, as the "Acknowledgements" section and the copyright page (2) implies, the target audience for this type of thing is the kind of organization that enjoys the use of CMMI. It was one of the greater realizations in my career when I learned that CMMI isn't necessarily trying to improve software engineering as much as it is trying to make whatever process you have repeatable. It took you 6 months to make "hello world"? Great, please don't let it take you 5 or 7 months the next time. And that segues into another aspect that you hinted at in your "2b, 2a, 2b" clause which is unlike traditional engineering disciplines, software engineering is almost always building something that no one has ever seen or imagined before. Thus, when asked to plan out what one is going to do that day, it's mostly "create a mental map of this unknown landscape as I discover where the theory meets the practice." It is absolutely helpful to have libraries and application servers, etc, but as for knowing _exactly_ what to type and exactly how long it should take to make another component that's shaped like the component from last week but who's innards are entirely different: good luck to us all.

by efaref 12y ago

diego 12y ago

PSP was not designed for consumer apps. It was conceived for mission-critical software that needs to be right the first time, such as the Space Shuttle's (400K LOC). I took a class on PSP at CMU in the 90s and it was obvious that I'd never use it at any of the companies I was interviewing with at the time. Your comment sounds to me as if a dentist said "look at this jackhammer, what a useless tool. I'll never put this inside anyone's mouth."

0xdeadbeefbabe 12y ago
This is an insult to jackhammers.
HeyLaughingBoy 12y ago
You'd be surprised. Having (been forced to) used PSP for the last 4-5 years, I'm not such a huge fan of it, but a surprisingly large number of companies building consumer software are adopting PSP/TSP.

mdaniel 12y ago

I have two small corollaries to your description. The first is that, as the "Acknowledgements" section and the copyright page (2) implies, the target audience for this type of thing is the kind of organization that enjoys the use of CMMI. It was one of the greater realizations in my career when I learned that CMMI isn't necessarily trying to improve software engineering as much as it is trying to make whatever process you have repeatable. It took you 6 months to make "hello world"? Great, please don't let it take you 5 or 7 months the next time. And that segues into another aspect that you hinted at in your "2b, 2a, 2b" clause which is unlike traditional engineering disciplines, software engineering is almost always building something that no one has ever seen or imagined before. Thus, when asked to plan out what one is going to do that day, it's mostly "create a mental map of this unknown landscape as I discover where the theory meets the practice." It is absolutely helpful to have libraries and application servers, etc, but as for knowing _exactly_ what to type and exactly how long it should take to make another component that's shaped like the component from last week but who's innards are entirely different: good luck to us all.