The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Econ 101 Management - Least of my Worries

Management style is important, I'll give you that.  Closer to home I worry more about the filth spewed by Carnegie Mellon regarding the practice of software development and support.


We're faced with a growing intrusion of this bilious philosophy, promoted by a group of mincing courtiers who are mostly failed developers, hyper-promoted secretaries, and community college management course attendees.  In other words the brightest lights in software development.

Hype of the day is some load of crap labeled "SEM" to give it an air of significance and all the weight of a TLA.

This process seems to consist of yet another layer of bureaucracy, heavily laden with platitudes of the "family values" ilk that sound good to the uninformed.  Typically the copy/pasted terminology is used inappropriately (e.g. "implementation" is used when they mean "deployment").

The process of actually developing software is demoted to "construction" - yes, they actually use that very term!

Construction is paraphrased as:

"The goal of this stage is to translate the set of technical, computer-oriented system design specifications into a language the computer can understand and execute."


So here we go.  Another generation of idiots trying to apply Henry Ford's assembly line principle to software development.  They seriously believe that defining requirements, designing a solution outline, developing an actual solution, properly testing the result, etc. are isolable stages to be performed by different "teams" (here we go again!) of people.  Different stations on that assembly line if you will.

This is not engineering, it's idiocy.


Won't somebody stop them before they kill again?
Dis Gruntled
Sunday, May 13, 2007
 
 
-- With apologies to "The Shawshank Redemption" --

SOFTWARE PROJECT LEAD CABAL MEMBER #1
Your resume says you've worked in software engineering over 30 years.  Do you feel you can work within the framework of our Software Engineering Methodology?

** Red doesn't answer. Just stares off. Seconds tick by. The committee exchanges glances. Somebody clears his throat. **

MEMBER #1
Shall I repeat the question?

RED
I heard you. SEM. Let's see now. You know, come to think of it, I have no idea what that means.

MEMBER #2
Well, it's a structured process that provides guidance for information systems engineering related project management activities and quality assurance practices and procedures...

RED
I know what you think it means. Me, I think it's a made-up word, a politician's word. A word so fellas like you can wear a suit and tie and have a job. What do you really want to know? Am I a "team player? Can I meet my deadlines? Is my defect rate low? Do I put the proper cover sheets on my TPS Reports?

MEMBER #2
Well... are you?

RED
Not a day goes by I don't feel regret, and not because I'm in here or because you think I should. I look back on myself the way I was...stupid kid who thoughht that computer programming was an interesting challenge, even fun... wish I could talk sense to him. Tell him how things are. But I can't. That kid's long gone, this old man is all that's left, and I have to live with that.

Methodology? That's a bullshit word, so you just go on ahead and stamp that form there, sonny, and stop wasting my damn time. I've seen the Methodologies and the James Martins come and go. Truth is, I don't give a shit.

** The project lead committee just stares. Red sits drumming his fingers. **

CLOSEUP -- APPLICATION FORM
A big rubber stamp SLAMS down -- and lifts away to reveal the word "APPROVED" in red ink.
Justinian
Sunday, May 13, 2007
 
 
Memeber 3:

*chuckles with glee*
Another slave for the mines.  Looks like we'll get that bonus after all.
Codger
Sunday, May 13, 2007
 
 
> Construction is paraphrased as:
> "The goal of this stage is to translate the set of technical, computer-oriented system design specifications into a language the computer can understand and execute."

That's not construction, that's compilation. If the SEI doesn't understand the difference, why would anyone listen to them?

(Fair disclosure: I follow some SEI stuff, namely PSP, but hadn't noticed the things you quoted.)
Meghraj Reddy
Sunday, May 13, 2007
 
 
+5 Justinian
Meghraj Reddy
Sunday, May 13, 2007
 
 
I don't know if it came from SEM or not but the distinction most businesses make between "implement" and "develop" is pretty useful.

Of course, if you are are a developer then all implementations seem to involve development....
Arethuza
Sunday, May 13, 2007
 
 
> That's not construction, that's compilation.

I think it's called "coding": it's the bit which happens after the "[high-level] design".

That terminology isn't new; for example I think that the introduction to the first edition of _Code Complete_ says that that book is mostly about the "construction" phase: defining functions, writing lines of code ... after analysis and design, and before testing and deployment.

If "construction" is what McConnell calls it then that's good enough for me: I too use that term occasionally for that activity.

> They seriously believe that defining requirements, designing a solution outline, developing an actual solution, properly testing the result, etc. are isolable stages to be performed by different "teams"

Those are two other topics:

* Do you do several activities (e.g. design and construction, or test and construction, or requirements and construction) simultaneously? Sequentially? Iteratively?

* Does one person do all activities? One team? Several teams?

> The process of actually developing software is demoted to "construction" - yes, they actually use that very term!

Does your vocabulary equate "construction" with "no-skill assembly-line work", which is why you seem shocked and offended?
Christopher Wells Send private email
Sunday, May 13, 2007
 
 
> They seriously believe that defining requirements, designing a solution outline, developing an actual solution, properly testing the result, etc. are isolable stages to be performed by different "teams".

When you're talking about millions of lines of code for safety critical applications how else would you do it?  Everyone is an independent auditor.

In my world it's:
- Deriving Requirements
- Mechanization
- Coding
- Testing
- Rinse and repeat
 
So that if all do there job correctly no anomalies are found and the code doesn't crash.  And if one doesn't anomalies are found.

In small shops I see your argument, although testing should still have some flavor of independency, but who says they're talking about small shops?
Gecko Send private email
Sunday, May 13, 2007
 
 
"If "construction" is what McConnell calls it then that's good enough for me"

Let's just cite a well known author and then declare it the truth.

McConnell has a lot of good advise. But he's wrong about a lot of things too. Like the construction metaphor he pushes so strongly he NAMED HIS COMPANY AFTER IT. (Construx)

But LAYING BRICKS and DEVELOPING SOFTWARE are NOT THE SAME THING.

And any one who feels they are reasonably compared is, to be sure, a fool.
Meghraj Reddy
Monday, May 14, 2007
 
 
> Does your vocabulary equate "construction" with "no-skill assembly-line work"

Nope, but your quip here is just a distraction. The thing about construction is that IT IS NOT DESIGN. Yet, all programming I have ever seen is when the detailed design occurs. Yes, it helps to have a high level design as well. Which, unless the program has already been written 1000 times, is probably wrong and will be changed once the nuances of the low level design are understood.
Meghraj Reddy
Monday, May 14, 2007
 
 
> Let's just cite a well known author and then declare it the truth.

It's not a question of "the truth", it's a matter of "definition" and of standard (or standardized, or common) terminology. Some people use bits of 'software pattern language' for example, like "bridge" or "visitor", as a *technical* term (not as a 'metaphor'): and similarly "construction" may be a technical term from the software engineering lexicon.

It isn't too inept: http://www.google.ca/search?hl=en&q=define%3Aconstruction suggests that "construction" doesn't necessarily mean "laying bricks".

I don't know whether you've done much coding or read _Code Complete_, but coding can be quite methodical.

> The thing about construction is that IT IS NOT DESIGN. Yet, all programming I have ever seen is when the detailed design occurs.

There are different styles of software, project, and process. Some are more iterative or informal, with less up-front design.

I find myself merging design with coding more on projects where I'm the sole developer, and less on other pojects.

The traditional SDLC includes high-level design, detailed design, and coding ... and it's true that there's some overlap or synonymity between detailed design and coding.

You said that if "The goal of this stage is to translate the set of technical, computer-oriented system design specifications into a language the computer can understand and execute" then "this stage" must mean "compilation" ... but I think that the "language the computer can understand and execute" might mean "source code": because in my experience (telecomms programming) "the set of technical, computer-oriented system design specifications" might include:

* finite state machine sequences
* input/output message formats
* sequence diagrams
* configuration data
* software architecture
* available APIs

which are technical and computer oriented, but not executable. They may well be correct though, and complete, and I'd say that you can "construct" software from them.

Maybe "construction" is more clearly a separate activity in some types of domain than others: telecoms is one; then Gecko is mentioning million-line safety-critical applications. Sometimes you don't have all the requirements and design in place before coding; sometimes you do.

Even when I don't, I see the phases as distinct; when I'm picturing a UML class disagram that's design, and when I'm coding the class declaration that's construction: they're nearly the same, but a different mentality: the design elements implement the function spec., and the code implements the design; the coding is the construction phase.

I've done design-and-code-on-the-fly as well, in various projects: I agree than sometimes (or even often or always, depending on where and how you work) construction-and-distinct-from-design doesn't exist; but, honestly, sometimes it does.

> This is not engineering, it's idiocy.

Engineered software systems can be pretty reliable. And they can be larger than anything that any one person or team can write: if it's large enough then you need to partition it; and if you need to partition it, then you need to design the pieces (especially the interfaces between the pieces) before you write (or construct) the pieces themselves ... at least, that's what I was taught.
Christopher Wells Send private email
Monday, May 14, 2007
 
 
If you don't separate out the requirements gathering from the development from the quality assurance, and you handle money at all, the SOX people come after you.  Maybe it's different with small companies, but someplace like a bank is highly structured like this because they have to be auditable.  It's a fairly significant security risk.

I don't fret about how people define their terms; I try to pay attention to what they do with them once they're defined.  The language is a tool, not the end goal.
moop
Monday, May 14, 2007
 
 
I don't think it's about the labels at all.  I suspect the dissatisfaction is with how few people in the boat are pulling oars compared with how many are there to shout "stroke! stroke!" through their paper megaphones.

Adding staffing supercargo and a patent medicine "process" doesn't guarantee a thing about auditability.  You need quality staff throughout the software life cycle, you just can't escape the fact.

It doesn't do a lot of good to have a towering, predefined form laden, "step by step" process... that people follow blindly as best they can.  Very quickly you reach a point where an audit will reveal paper trails leading nowhere and meaning nothing as a result of cargo cult process being carried out.

Ultimately you need to throw the process out and hire smart people with integrity instead of trying to get by with a gaggle of relatives, sycophants, and share-cropping contractors.

I don't want to hear about SOX compliance.  We all know why this band-aid was put in place and how little good it is doing right now.  Lots of us have friends working in the big auditing firms and we know where NOT to be putting our money.
Jade G.
Monday, May 14, 2007
 
 
Prediction:

Software Engineering Gurus who don't write code will continue to invent "processes" that make software development seem easy, stable, predictable, and repeatable.

Some of them will even work.

Companies that do work for the US Department of Defense will continue to be forced to follow these standards - or, at least, make it look like they are following them.

Companies that compete in a free, non-monopoly market will continue to ignore these "standards."  Those that attempt to comply with the "standard" will, generally, have terrible results and often fail in the marketplace.  A few will succeed, which will make things even harder for those of us who think the standard is intellectually brain-dead.

This is not new; for a more detailed explanation, go google "James Bach Immaturity of the CMM"

I'll be talking to James Bach at STAREast this week; if you read the article and have a question, email it to me - I'll ask him.

Regards,
Matthew Heusser Send private email
Monday, May 14, 2007
 
 
I think Dis Gruntled is... well... disgrunted and just venting his opinion. Even the Software Engineering Institute readily admits that CMM and other rigidly structured software development lifecycle methodologies are not appropriate for every circumstance.

The value of these methodologies aside, the real issue is that there's no way to objectively measure programmer productivity and predict the quality of work performed. That doesn't mean however that you should give developers a blank check. A compromise must be struck; developers need the freedom to treat each scenario on a case by case basis while providing some sense of accountability. When we hear about problems, it's usually a result of someone going too far towards one extreme or the other.

If you know of a manager that's insisting on one approach that's clearly not appropriate, the best thing to do is offer some constructive criticism. Show them on the ledger that it's cheaper, faster and results in higher quality if they do [some specific technique] instead of what they're doing now.

As the saying goes, if you're not part of the solution, you're part of the problem.
TheDavid
Monday, May 14, 2007
 
 
I have published a surprisingly high number of articles on this topic:

"Why I am not an architect" - for Dr. Dobbs:
http://www.ddj.com/documents/s=9776/ddj1115934034281/heusser1.htm

"Tomorrows Software Factory - Today" again for DDJ
http://www.ddj.com/documents/s=9776/ddj1138719636482/heussr3.htm

"Don't just take two aspirin" - Software Test&Performance, Pg. 42
http://www.xndev.com/articles/stp-2005-08.pdf

"A New Strategy" - Better Software Magazine
http://www.xndev.com/articles/ANewStrategy.pdf

hmm ... interesting pattern, that ...
Matthew Heusser Send private email
Monday, May 14, 2007
 
 
While I don't think much of McConnel and Code Complete, but there IS something to all this process crap. It isn't so much that we really want to separate each stage of the deveoplment process into separate tasks performed by different people (though we may want to do that, if we have different people in the organization who have strengths and weaknesses in different areas). The real benefit of most processes is that you generate a reliable record of what you meant do, and you get agreement from other parties on the plan.

Generating requirements and specifications, on any project of reasonable size, is non-trivial and can't be done in an ad-hoc manner. You really do need written customer requirements and design specifications so that, several months into the project, when you run into an odd corner case in the code, you can refer back to the customer agreed requirements and specifications to decide what to do (not to mention being able to point to signed documents when the customer complains that the end product is not what they asked for).

The case for design documents is a bit less clear cut: the usefullness of detailed UML diagrams when writing the code is, in my view, marginal. The real value of design documents, however, comes when the code is in maintenance phase and the design documents represent a short cut to understanding the structure of the system. In this case, design documents should be written after the actual code is written, not before.
Jeff Dutky Send private email
Monday, May 14, 2007
 
 
Nice articles.  A bit subversive maybe, but I mean that in a good way..
Codger
Monday, May 14, 2007
 
 
> The value of these methodologies aside, the real issue is that there's no way to objectively measure programmer productivity and predict the quality of work performed.

Yes there is. Ask multiple developers/teams/companies for bids on the same project. Track whose estimates are shortest. (Looking just at man-hours, not budget.) Also track who consistently makes their estimates.

You might say that this only addresses productivity, or estimating skill. But I think it will match quality, too. In Joel's "High Notes" post ( http://www.joelonsoftware.com/articles/HighNotes.html ) he says that 100 Salieris will never produce Mozart's Requiem. Then he admits that most software doesn't require the "high notes".

So for the majority of programming work, you don't need rock stars to pull it off. What happens if you hire one anyway? Does it help productivity?

From the graph and discussion of the Yale programming course statistics you would think the answer is "no". Joel even says, "In fact when you look closely at the data it's pretty clear there's *no discernable correlation between the time and score*."

I wish that data included lines of code. I suspect -- through experience but no rigorous evidence -- that lines of code went up as time went up. Good programmers can improve someone else's code, and sometimes their own, by deleting code. Bad programmers *always* fix bugs by adding code.

Fail an automated test? Add a special case to handle that input. Change the spec? Add more code to handle it. Every change makes the code more brittle.

Look back at the chart. There was one score in the high 50s at just over 10 hours. There was another in the high 50s at just under 40 hours. Without having seen the code, I'd bet that the 40-hour solution had at least twice the LOC. Which means it will take twice as long to update and twice as long to test the updates.

When someone's estimates are consistently shorter than everyone else's, and they make their estimates, that means that problems are easier for that person. So their code will be shorter and more maintainable.

As long as you have a consistent way to set acceptance criteria, whoever consistently finishes fastest is probably also producing the best code.
Drew K
Monday, May 14, 2007
 
 
> You really do need written customer requirements and design specifications so that, several months into the project, when you run into an odd corner case in the code, you can refer back to the customer agreed requirements and specifications to decide what to do (not to mention being able to point to signed documents when the customer complains that the end product is not what they asked for).

No and yes.

No: In the odd corner case, it's likely the specifications really don't cover what to do. You have to work out the correct solution.

Yes: The documentation will make it clear whether the correct solution is covered in the contract or if the customer has to pay more.

I may be picking nits if you really meant what I just said, but I've worked with plenty of people who take the position that, "It doesn't matter what actually works, we've got a written spec and that's what we're going to write."
Drew K
Monday, May 14, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz