Fog Creek Software
Discussion Board




This chef has no clothes

In the Naked Chef:

http://www.joelonsoftware.com/articles/fog0000000024.html

Joel talks about methodologies and such.  Joel makes a good argument, and I agree that methodologies are dangerous.  But I also worry that too many programmers work in the 'Naked Chef' fashion.

Programs that are released to the public, or that interact with the internet in any fashion, are not the programs to have put together in the 'Naked Chef' fashion.  A little code here, a little code there, and suddenly I'm better off finding a new job than try to take responsibility for what I just wrote. Maintainability and security can't be done 'Naked Chef' style.

I think doing things ad-hoc worked great the first few decades of the computer revolution. It works great for small in-house projects. But I think the time has come to start turning our profession into an engineering one.

Unfortunately this involves writing out boring things like specification documents, which Joel recommends:

http://www.joelonsoftware.com/articles/NothingIsSimple.html

...and setting up schedules, doing reviews, better QA, etc.  Luckily the Naked Chef doesn't have to maintain his meal after it has been put together, or spend a year creating it.

It doesn't take an engineer to make a bridge to cross a ditch. However many programs are now starting to resemble the Golden Gate Bridge in terms of the time, effort, and money involved.  As software programs actually start to have lifetimes measured in decades, I think project managers are going to start looking at engineers to do development, and programmers will simply be the laborers doing the welding on the bridge.

Likewise, methodologies don't work. Each bridge is different.  Each development project is different. There is no 'one' way that can work for each project.

There is a class of people that prefer coding over doing requirement specifications, functional specifications, detailed code reviews, metrics, attending any kind of meeting, etc.  Look at your bookshelf.  Do you have only technical books on it?  Or do you have books on managing projects?  I think the tech-only people will soon be limited to being skilled laborers.  What do you think?

Paul Vincent Craven
Monday, June 10, 2002

Paul,

I think its already happened.  Sure, there will always be superstar programmers just like there are superstar chefs, but the truth of the matter is that the majority of people working in catering are working for a fast food outlet.

One big problem, I think, is that the division is coming about too early.  Many programmers are getting poorly paid desparately trying to make the half cocked designs work.

Ged Byrne
Monday, June 10, 2002

I don't think so.  I've noticed less of a compartmentalization around my digs.  Most of the verts I see want a be-all end-all software architect/programmer/business analyst.  I think the market, at least for the next several years, will dictate that really good architects will also be doing really good programming and face work.

those who know me have no need of my name
Monday, June 10, 2002

I think you underestimate the ad-hoc approach.  It's as if the ad-hoc people were complete sitcom morons, while those who tote specs 'n metrics live in a more rarefied atmosphere.

The ad-hoc people are at the forefront, experimenting with new methods of communication, using specs and meetings As Needed.  Some are monumentally terrible, but so are their alternate-universe counterparts in engineering.  All would be well-advised to learn from the other.

Anyway, I think this focus on engineering and code is still too technical a worldview.  There are many more pieces to the puzzle.  As it stands, there are few companies that could do good engineering if they wanted to, and it's a double-coincidence for them to be successful as businesses.

Sammy
Monday, June 10, 2002

Would you really want an 'ad-hoc' approach to your business's critical infrastructure? Or anything else important?

"I have no idea how much load this bridge handles. Probably quite a bit. Let's just test it by driving a few trucks over it."

"What happens when you enter 255 characters into a 10 character field? Hmm, never spec'd that out. Not sure."

"What happens when the database is overloaded by another app? Not sure.  But hey, you got your system built for $20 and a bunch of free pizza, so don't complain."

And would you really want your business relying on people messing around with 'experimental' techniques.  I've seen experimental computer code from code cowboys. Rarely does one make a scientific experiment out of it. Normally it only sees a few minimal tests on the developers machine.

There are many pieces to puzzle in creating a building, bridge, or anything else that currently requires good engineering.  I'm not saying those pieces don't need to be there. I'm just asking if large software projects shouldn't include the piece of 'real engineering'.

Paul Vincent Craven
Monday, June 10, 2002

Paul Vincent Craven wrote:
"I have no idea how much load this bridge handles. Probably quite a bit. Let's just test it by driving a few trucks over it."

The great thing about creating software is that you can actually do that. If the bridge collapses, no damage is done, because it's only bits falling over. That's a huge difference.

Also a naked chef developer knows how to test, just like the real naked chef knows how to taste his dishes to make sure it is perfect. And he does that without strict rules, because he is that good. It's the mediocre guy who needs a thermometer and a rule telling him to use it, to make sure the soup is not too hot.

Jan Derk
Monday, June 10, 2002

>> Would you really want an 'ad-hoc' approach to your business's critical infrastructure? Or anything else important?

"I have no idea how much load this bridge handles. Probably quite a bit. Let's just test it by driving a few trucks over it." <<

I agree with what Jan's statement that testing a "software bridge" is much cheaper.

I think Paul gives too much credit to the "engineers".  Large engineering projects require a great deal of time and effort to produce requirements and designs. Sometimes these designs still have critical flaws. Have you ever heard of the Tacoma Narrows Collapse?

How many times have you heard of a bridge or large building getting constructed halfway and then moved to another location? These types of requirements frequently change in the software world. If you eliminated ad-hoc development I think it would be much harder to change requirements mid-project (maybe a good thing to some).

Anyway, I agree that some engineering practices would be good. But I disagree that "ad-hoc" techniques are not useful.

NathanJ
Monday, June 10, 2002

Much has already been said on either side of the argument, so I just want to add..

..I love the Naked Chef reference.  I use his recipes quite often.

Marty Eichelman
Monday, June 10, 2002

One thing people underestimate is software is cheaper than bridge, by a facto of 1000 or so. Just as an example look at what retrofitting the bay bridge (for those of you in the bay area) is gonna cost! The reason? precisely what was mentioned before they are intent on engineers/consultants/unions doing it, checking environmental impacts,safety, politics, all this costs money and has a ton of overhead.  until a time comes that people are willing to spend millions on the system overhead alone, we will have naked chefs it is simply more efficient.

Daniel Shchyokin
Monday, June 10, 2002

I'm a hardware design engineer, which may explain why I find this thread so confusing and contradictory.  The first message seems to suggest that:

1) Methodologies don't work.

2) It's time for software folks to set aside the ad-hoc approaches of the past.

3) Writing specifications, having reviews, etc., may be a good place to start.

To which I respond: huh?

What are specifications, reviews, etc., if not aspects of methodology?

I think that there's a fundamental misunderstanding about what methodology does.  A sound methodology does not make it possible for an unqualified person to do the job of a good person.  Rather, a sound methodology makes it possible for a good person to do his job more efficiently. 
Writing specs and holding reviews may not be enjoyable, but they save tons of time at the end of the project (you know, the second 90% of the job) by eliminating dumb mistakes that are much tougher to fix later. 

The same goes for the checklists that I've created over the years, from hard experience.  These checklists wouldn't mean much to a freshly-graduated engineer, but for someone who's done design, they save time and mistakes.  Again, it's appropriate methodology.  What's inappropriate methodology?  Well, the kind of crappy, pre-fab procedures that often arise from ISO 9000 certification efforts come to mind.

Good methodologies are not static.  The hardware methodologies I used to design 4 MHz logic in the mid-70's are no longer sufficient at 2.5GHz.  And no single methodology fits all situations.  But neither of these realities is an argument against having a methodology.

One other thing: in hardware design we have no small number of hardware "artists" who think they're above methodology.  The ratio of hardware designers who think they don't need methodology to the geniuses who truly don't is probably about 100:1.  I don't know what the ratio would be in the software world.

Bob Perlman
Monday, June 10, 2002

BTW, I hope I didn't sound confrontational earlier, just sorta musing with my fingers.

For large projects, you are absolutely right.  SEI defines software eng as, "the computer science discipline concerned with developing large applications."  That's when software building approaches bridge-building.  The Project is alive, and has an attitude.

Unfortunately, you wrote, "programmers will simply be the laborers doing the welding on the bridge."  Even in companies that canonize the programmers, this worldview marginalizes those at the bottom, as well as the inexperienced.  The resulting morale loss may overwhelm the gains from engineering.

Sammy
Monday, June 10, 2002

What?!  You fools!  I do TOO have a Methodology!  When you are as good as me, you just make it LOOK easy!

Aromatic Salmon Cooked In Coconut Milk

Method:
1. Put the fish steaks in a fairly shallow oven-proof dish with a lid, into which they fit quite closely.
2. Scatter the ginger, garlic, tomato, chilli and yellow pepper over and around the fish and the cardamom pods in between.
3. Empty the coconut milk into a separate bowl, add a good sprinkling of sea salt and gradually stir in the lime juice. Pour the mixture gently over and around the fish and cover the dish.
4. Preheat the oven to 150C. Put the dish on the centre shelf and cook for 40-50 minutes, until the fish is lightly done. To discover this insert a small, sharp knife into the centre of one of the steaks – if the flesh is slightly darker pink in the centre it will be perfectly cooked. Remove from the oven.
5. Before serving scatter the mint leaves on top.

Tomorrow I will improvise a new recipe and add it to my Operations Manual (r) so that my junior chefs can add it to the menu in my other restaurants.  Yes, the salmon will taste a little differently in the Seattle Salmon Shop than it does in the Saskatchewan Salmon Smoker, but that's OK.  My customers are discerning enough to appreciate the variety the different locales afford.  Anyway, it's time for a new Operations Manual (r) because just the other day, one of my junior chefs at Freddie's Frogleg Fantasy created an absolutely exquisite Dandelion Frog Suprise!

Remember this above all else, Junior Chefs:  Repeatability DOES NOT equal Poor Quality!

nekkid chef
Monday, June 10, 2002

<<I agree with what Jan's statement that testing a "software bridge" is much cheaper.>>

I do not agree. The operational context of the bridge is a lott less fickle than that of the software program. The bridge will not suddenly collapse because someone swapped a "6" wit a "G" on the front licence plate of te third testing truck, whereas the software ...

There is no limit to the immediate impact of one bit changes.

As to the add-hoc versus methodological approach: Most of the things I've seen I would place under the heading "cargo-cult methodology" (as in Feynman's "Cargo Cult Science"). We go through the motions of methodology, but it is just for the sake of it. We have no undestanding of what realy improves the software construction phase, just some very biased anecdotal evidence. Heck, we are not even close to agreeing how to measure or compare. There is no "Physics" of software. There isn't even a chemistry or biology of software and our "software engineering" is to real enineering as astrology is to astronomy.

Just me (Sir to you)
Tuesday, June 11, 2002

"We have no undestanding of what realy improves the software construction phase"


Actually we do.  Pick any number of books on software engineering and you will be bombarded with statistics.

those who know me have no need of my name
Tuesday, June 11, 2002

----------------------------------------------------------------------
Actually we do. Pick any number of books on software engineering and you will be bombarded with statistics.
------------------------------------------------------------Those ...

But how worth while are the statistics?

eg. The KLOC/M was greatly increased when the programmers started using the clipboard rather than functions.

Ged Byrne
Tuesday, June 11, 2002

This point is not even debateable.

An engineer can "prove" mathematically that his bridge will hold against x pounds. If it doesn't, it's his fault - he calculated wrong, because the laws are known and understood.

Can you "prove" that your program won't crash when I install Quicken? or that it will handle 10,000,000 transactions/sec? or that it will only utilize 50% of CPU resources?

Software engineering? Give me a break . . .

Those who want to get to know you need your name to do so, however.
Tuesday, June 11, 2002

"But how worth while are the statistics?"

That's a good question for which I don't have an answer.  Unfortunately the only data that is readily available comes from BIG government/military projects.  Businesses don't usually like to air their dirty laundry.  I have a hunch that the dynamics are different enough that it probably makes a difference.  Even so, I do know that there are certain best practices that, when followed, lead to a better product that tends to ship on-time & under-budget.

Even if that methodology is simply known as 'The Joel Test'.

those who know me have no need of my name
Tuesday, June 11, 2002

>>
An engineer can "prove" mathematically that his bridge will hold against x pounds. If it doesn't, it's his fault - he calculated wrong, because the laws are known and understood.

Can you "prove" that your program won't crash when I install Quicken? or that it will handle 10,000,000 transactions/sec? or that it will only utilize 50% of CPU resources?
<<

Sure I can prove it. By having good specifications, I can tell you what unmodified OS's my program works with, and what resources it requires. If you install Quicken, don't run me lower than x on resources, and don't mess with the files I depend on, I'll run just fine. Any other action is a bug.

I can easily prove how many transactions per second my system will handle.  In a good design document, I can see the time-critical pieces.  If I'm not sure they will make the spec, I run experiments.

The road is littered with failed projects that cost tens of millions, if not hundred of millions of dollars.  As much as a bridge.  Check out 'Software Runaways' for a few examples.

I still believe that before you commit your business on a system, you had better be darned sure it works.  Fully design the system before you build it. If you aren't sure something will work, do an experiment to see if it will.

Here's a quote from a 1996 Wall Street Journal article:

"In 1994, when FoxMeyer Drug Co. was showing off plans for a $65 million computerized system to manage critical operations, then-Chief Information Officer Robert R. Brown told the trade publication Computerworld: 'We are betting our company on this.'

"They lost."

FoxMeyer had 5.1 billion dollars in sales in 1995, and filed for bankruptcy-court protection the next year.

Paul Vincent Craven
Tuesday, June 11, 2002

-------------------------------------------------

Software engineering? Give me a break . . .

-------------------------------------------------


Who said anything about proofs?  What point isn't debatable?  If we define a methodology as:  "A body of practices, procedures, and rules used by those who work in a discipline",  is 'The Joel Test' not a methodology???  It sure sounds like one to me, no matter what he claims otherwise. 

Before you make any more ASSumptions, I'd like to point out that I don't view programming as being the same as engineering.

those who know me have no need of my name
Tuesday, June 11, 2002

"The ad-hoc people are at the forefront, experimenting with new methods of communication"

Too me it means its absolute crap with a snappy sound label. I guess you could call German House Music on the "forefront of new methods of communication" but I think crappy and loud work just as well.

Frankly, the forefront doesn't get you much. You may get respect, but you don't get much else. We could all name the founders of the World Wide Web. But in the end, the winners were not the founders. It was companies like Microsoft who used a legion of smart, but very structured, code warriors to will the war.

So, you stay on the forefront. You come up with great ideas. I'll stay back here and use those ideas to build an empire. :)

Marc LaFleur
Tuesday, June 11, 2002

Proving *somekind* of statistic about software and following a methodology are two different things.  Big M methodologies always have a builtin excuse against failure... if it didn't work, then you obviously didn't follow it correctly.

Think about this... can you name any formal studies that proved conclusively and beyond any doubt that a formal approach to anything is better?

Wouldn't that be like having the fox guard the henhouse?

No, we have been conditioned to believe it is true.  Sometimes it works, sometimes it doesn't... just like the alternative.

I believe what it comes down to... is the basic motivation and desire of the individual(s) involved - the "want" to make it work.  Without that, no approach, formal or otherwise will succeed. 

It's in the mind, not the process.

Joe AA.
Tuesday, June 11, 2002

Someone with a long name wrote:
<<An engineer can "prove" mathematically that his bridge will hold against x pounds. If it doesn't, it's his fault - he calculated wrong, because the laws are known and understood.>>

Not entirely true. While engineering models are far more sophisticated than software development models they still do simplify matters. What if the concrete degrades and causes the bridge to fail? Or a ship hits one of the pylons and brings down the bridge because the model from 30 years ago had not accounted for ships to be this heavy? Still his fault?

Proof is relative. Engineering can be quite complex and is not as simple as it sounds. It's generally not the streamlined calculated process that many software developer seem to think it is. There are many uncertainties and testing is done a lot.

<<Can you "prove" that your program won't crash when I install Quicken? or that it will handle 10,000,000 transactions/sec? or that it will only utilize 50% of CPU resources?>>

Just like Paul said: yes you can prove that. Software development always takes such requirements into account and tests for them during the development. However I do agree that the tools and models available to the software engineer are generally much more limited that those available to a construction/aerospace/whatever engineer. In software development the estimations are generally made by experienced developers.

Jan Derk
Tuesday, June 11, 2002

"It's in the mind, not the process. "

Yes and no.  As I stated in my original posting, I don't think methodologies are all that great.  For instance, "We use 'RUP' here on our projects."  That doesn't always work so hot because RUP adds a lot of overhead.

The 'Naked Chef' way would not have you using any methodology, list, or anything else. Just what is in your mind. Great for food, bad for large software projects. (I make no claim on small or even medium sized projects.)

The true software engineer doesn't follow a methodology for the sake of just following it. He or she understands why each point in that methodology exsits.  He or she adapts it to a project as appropriate.  The process is improved as time goes on.

Without a process, I would not remember to check all zillions of things that need to be considered in a project.  Perhaps I could if I worked on projects that are 50k lines or less of code. But huge projects that span multiple databases, web services, and mainframe systems require more work.  What I need is engineering. Not random code-slinging and not a pre-packaged methodology.

Paul Vincent Craven
Tuesday, June 11, 2002

> So, you stay on the forefront. You come up with great
> ideas. I'll stay back here and use those ideas to build an
> empire. :)

You may be half-joking, but that's precisely how large, agile companies think.  ;-P  Small companies are labs.  They exist to do R&D for companies that have rejected the Not Invented Here syndrome.

Course, small companies often live to wreck distateful larger ones, so fair play.

The problem is that your dark empire will not be able to track my marauders, unless you are intelligently decentralized.  This entire thread is about minimizing risk, of ensuring stable monolithic systems for the large enterprise.  But few of us live in that world; most of us use Windows on consumer machines, decreasing risk of data loss by CVS and optical backups.  Multiple systems make up for each one's weaknesses.  Certainly more stable than most governments.

In the IT world, there are very few Real Experiments.  We mostly use 30 year old technology, and only the rudiments of that.  There are books of algorithms, design patterns, architectures, tools with built-in intelligence.  I couldn't be dangerously experimental if I tried.

The original poster complained of bad coders, who didn't use a single best practice.  Nothing to argue with.  But then he extended it by saying that pure tech people will be second class citizens, against the wall when la revolución comes.  That's the interesting point, because it probably already is the status quo.

Sammy
Tuesday, June 11, 2002

or that it will handle 10,000,000 transactions/sec?....

Yes we can prove that this works, its called testing

an intersting thing about physics in software occured to me though, that for a program the world of "physics" is essentially the machine and/or os it is on, put your bridge (software program) on a 32 cpu machine and you have a different environment of "physics" than on a 1 cpu win 95!

Daniel Shchyokin
Tuesday, June 11, 2002

Regarding the "Bridge" comparisn:

The critical parts of bridges are constructed of a few (10's, 100's) different part types (cables, bolts, concrete slabs, steel collums, ...), each of wich have known critical characteristics and any instance can easily be examined for conformance. Furthermore, most relationships between the usefull characteristics and the required specs or resonably smooth (making the cable a bit thicker makes it a bit heavier and a bit stronger, a small nick in the tread makes it a bit less strong), so calculations and "overspeccing" are less of a problem. Even so, we still get it wrong sometimes.

Software constructs are made out of very many (1.000's 1.000.000's) different parts, each unique. This gives us a nightmare testing scenario right there. Furthermore, the relationship between small changes in the code and the result of that change is completely erratic, so we can't get away with "just make it twice as strong to be sure". Our testing has to cover the entire range, in every possible dimension.
It's like each cable of the bridge would be constructed out of a string of 1.000.000 molecules of 1.000 molecule types, strung in a unique arrangement and if we get just one of them wrong, that cable will snap when a blue Chevy crosses the bridge at 10:00 pm on a Monday.
It's a miracle some of it even works remotely.

Just me (Sir to you)
Tuesday, June 11, 2002

1-bit errors can certainly bring down bridges. Consider the recent collapse of a span of  the I-40 bridge over the Arkansas River in Oklahoma on May 26. When a passing barge captain blacked out (what I'd classify as a 1-bit error), the bridge was exposed to a discete, single event that ultimately caused the bridge's failure.

There was also a lack of design foresight: the bridge had no shielding against boats going *upstream*. Apparently most accidents on the Mississippi watershed occur when the tugs' engines fail, not their operators. But unlikely events, or worse their combinations, do on occasion occur.

Jim Baker
Tuesday, June 11, 2002


--

This discussion seems kind of fractured, with people arguing for both sides of mutually exclusive arguments.
Here's a link to Feynman's article which actually directly names 'methods' in his cargo cult critique:

http://www.lhup.edu/~dsimanek/cargocul.htm

--

Regarding claims that "I can design a large system with no bugs by using formal practices" I say "Ha" and "Double ha".

--

It's true that one can make programs be reliable if one knows the exact system it is running on and has a fixed OS and no chance of person using strange drivers or odd programs concurrently, but that is not the real world that is CAUSING much of the software instability problems that frustrate so many users. Thus, using formal method K can not solve the software quality problem on home PCs.
--

>>[can you prove] that it will handle 10,000,000 transactions/sec?....

>Yes we can prove that this works, its called testing

Absolutely one can prove it works once the program is designed built and executable, but I thought the debate was about proving stuff works during some sort of design process following some formal methodology that did not involve coding, hence the comparison to bridge design.

Personally , I belong to the school of thought that says coding IS design and C is a design specification language and 'building' is not done by low wage 'coders' - it is done by no-wage compilers.

X. J. Scott
Tuesday, June 11, 2002

Programming is easy. Absolutely falling off a log easy.

There are two things that complicate it:

1. The people that won't (for irrational, religious reasons) let you build it in the way you know will work. In Bridge terms, this is not being allowed to lay a huge slap of concrete thick enough to take the weight from A to B. Yeah, brute force, but also quite likely to work...


2. The fact that projects tend to run:

We need a bridge.

Hire bridge builders.

Decide on a material, usually the first thing to hand. Tell builders.

Decide on a design, usually the one the last project used. Even if that project failed. Tell builders.

Order builders to start work.

Have 6 months of meetings to try and decide on which river to cross...

Katie Lucas
Tuesday, June 11, 2002

3.  Scrap the project when it gets sufficiently late and over budget
4.  Go out & buy a ferry.

those who know me have no need of my name
Tuesday, June 11, 2002

"Personally , I belong to the school of thought that says coding IS design and C is a design specification language and 'building' is not done by low wage 'coders' - it is done by no-wage compilers. "

The actual code is way too nitty gritty to be a design document.  The design document is supposed to provide an overview of how the software works...it's not supposed to be the software itself.

OzzieGT
Tuesday, June 11, 2002

"The actual code is way too nitty gritty to be a design document."

Unless you are Yoda and you code in Scheme. ;)

those who know me have no need of my name
Tuesday, June 11, 2002

"The actual code is way too nitty gritty to be a design document. The design document is supposed to provide an overview of how the software works...it's not supposed to be the software itself. "

I respectfully disagree.

Let me use bridge design specifications as an example. The design documents of a bridge are in sufficient detail that one can hire a contractor who will build the bridge as it is designed. You can hire three different contractors and you will get the same bridge. Maybe they got the type K-5 steel beams from company A instead of B, but they are still type K-5 steel beams of a given size and composition.

Code is the same way. Code is not the product at all. The realization of program design is the executable program, just like the realization of bridge design is a actual bridge. Code is not a product that is built straightforwardly from a design using standard practices, but an executable program *is*. And the worker that creates that product is the compiler. Yes, the work of building the product from the design has been completely automated in our industry -- it is reliably and repeatably done by a robot called a compiler.

X. J. Scott
Tuesday, June 11, 2002

I'll have to try that sometime.

"Hey, Mr. MoneyMan, what do you want me to program for you?"
...
"I'm sorry, that isn't specific enough. I need source code for my specifications."

To figure out what your user wants, you need to start working on an English document.  Your code should implement their requirements.

Paul Vincent Craven
Tuesday, June 11, 2002

I don't believe the Naked Chef way is totally random.  Ad Hoc certainly doesn't mean "without thought".

A requirement doesn't have to be documented... either in one sentence, or in 50K sheets to be a requirement.  I can't remember where it comes from... "our last software project was a failure and produced 5 tons of paper... so our next project will be required to produce 10 tons of paper!"

Paul... if you leave out "pre-packaged methodologies" and our Naked Chef... then what is "engineering" to you?  Simply following a checklist?  Wouldn't that be like considering a paint-by-numbers picture the same as art?

Joe AA.
Tuesday, June 11, 2002

Testing is no proof.  There is no proof by example.  QED.

Nat Ersoz
Tuesday, June 11, 2002

"To figure out what your user wants, you need to start working on an English document. Your code should implement their requirements."

Hey Paul, exactly! That's why the code is the design!
(Of course the requirements analysis, though part of the design process, is not the design itself.)

X. J. Scott
Tuesday, June 11, 2002

X. J. Scott wrote:
<< The operational context of the bridge is a lott less fickle than that of the software program. The bridge will not suddenly collapse because someone swapped a "6" wit a "G" on the front licence plate of te third testing truck, whereas the software ...>>

Engineers generally implement fail safe principles. If one pylon fails, the others will still be strong enough to keep the bridge upright. Far to often software does not follow this same principle. Never should the unforeseen change of one bit cause a software application to fail. However, a good designer will implement it by using modular design and exception handling.


<< Here's a link to Feynman's article which actually directly names 'methods' in his cargo cult critique:
http://www.lhup.edu/~dsimanek/cargocul.htm >>

That's a very interesting read. Thanks for the link. If I would have heros, Richard Feinman would surely be one of them. This guy is so good at making complex things sound  astonishing simple. Go and read his "Surely you're joking, Mr Feinman" if you haven't done so already (highly recommended):

http://www.amazon.com/exec/obidos/ASIN/0393316041/qid=1023836062/sr=1-2/ref=sr_1_2/103-6155659-0608616


<< Personally , I belong to the school of thought that says coding IS design and C is a design specification language and 'building' is not done by low wage 'coders' - it is done by no-wage compilers. >>

Never really thought of it that way. It sounds almost too logical to be true.

Jan Derk
Tuesday, June 11, 2002

See
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
for a great discussion of the viewpoint that the source code *is* the design.

Ray Gardner
Tuesday, June 11, 2002

That's why I never document my code.  The code IS the documentation.  Wrong comments have burned me way too many times.

those who know me have no need of my name
Tuesday, June 11, 2002

When you say "I never document my code" do you mean "there are no comments in my code"? Your "wrong comments have burned me way too many times" implies no comments, which strikes me as ... misguided, perhaps.

To give you an example, I've got a comment in my code here which states "Move the object's position into the coordinate system of the 2D view frustum". This comment explains what the next bunch of vector and matrix operations does. Without that comment, in a week's time I won't have a clue what the code is doing. Obviously I'll change the comment if I change what the code does! My "methodology", if you can call it that, is to add succinct descriptions of _what_ each code block is doing.

But this has been discussed before in various threads about maintaining other people's code.

Adrian

Adrian Gilby
Tuesday, June 11, 2002

Yep.  That's what I'm saying.  If I feel like I need to comment a piece of code, I rewrite it until the feeling goes away.  On occasion I bring in a pair of fresh eyes to look at it and see if it makes sense to them.  Granted, I'm usually under the gun so occasionally I'll slip one in.  Usually along the lines of

// leave this alone for now, its used in that bit of magic below!

those who know me have no need of my name
Wednesday, June 12, 2002

X.J.Scott wrote:

"Let me use bridge design specifications as an example. The design documents of a bridge are in sufficient detail that one can hire a contractor who will build the bridge as it is designed. "

In that analogy wouldn't the design specs be exactly that? Design Specs? Therefore wouldn't what the bridge is made of be the code and the bridge itself the program?

So, try building a bridge without using design specs, one bolt/beam/slab of concrete at a time until you reach the other side and then tell me you'd feel safe driving over it...

I'll let you go first...

Jack lives over there -->
Wednesday, June 12, 2002

"Surely you're joking, Mr Feinman" is a good book.  The end of the book, talking about voodoo science is a great read.  That is actually where I started out seriously thinking about this subject.

Computer Science rarely employes science. It does math, or some smoke and mirrors thing to create a project. But rarely are there hyphothesis, experiments, and published results.

Few methodologies have any kind of actual proof that they actually help. This is what frustrates me when companies choose to adopt them.

An engineer, in my mind, would employ processes knowning the reasoning behind them.  For example:

"I know that documenting user requirements before I start coding saves time in all but the most trivial projects.  I've done both, I have read reports from other people who have done both. I have ample evidence doing this helps."

And when we teach programmers, we should not say "Write user requirement documents.".  That teaches them the methodology, not why it is there.  We have to get them to understand.  Here are the papers. Here are the experiments. Here is what happens if you do it, and if you don't.

There are hundreds, or thousands of software development problems like this. This kind of introspection and understanding isn't for everyone. It is boring and anal. But being an engineer isn't for everyone.

Paul Vincent Craven
Wednesday, June 12, 2002

Ray Gardner wrote:
<< See
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
for a great discussion of the viewpoint that the source code *is* the design. >>

What an eye-opener a 10 year old article can be. What have I been doing all this time? Thanks Ray.

Jan Derk
Wednesday, June 12, 2002

"An engineer, in my mind, would employ processes knowning the reasoning behind them"

Basically I agree... I use processes because of the benefit I know I can get out of them.  I don't consider myself an engineer though.

Writing down requirements is a good thing, as in your example, but it needs to go beyond that.  Most requirements type documents I have seen, and even further refinements such as functional or technical specs, tend to be like Moses bringing down the tablets - the user wants it, therefore it is a requirement.

What they seem to miss... is the "why" of the requirement in favor of the "what".  This causes a lot of rework.  It states a solution in isolation from the problem... forgetting that the ultimate goal is to solve the problem.

Joe AA.
Wednesday, June 12, 2002

This thread reminds me of some issues I've been noticing at work.

I work as a programmer in an accounting department.  When my fellow programmers and I are working on a big project, I notice other programmers getting irritated at how much responsibility the users want us to take on.  I often hear my programmer colleagues say, for instance, that they expect the users to define the business process, tell us what it is, and then we code accordingly.  (Much of our work is automating formerly paper-based processes.)

The irritation arises because sometimes the users -- even the bigwigs, the C.P.A's who run the department -- are not exactly sure what the business process is.  Maybe the business process is very messy.  Maybe certain decisions will have to be made in order to nail down the business process, remove its messy edges, so that it can be translated into code.

It occurred to me in a meeting today that maybe it IS our job, as I.T. professionals, to TELL THE SUITS WHAT THEIR BUSINESS PROCESS SHOULD BE.  We're not just drones, translating the well-defined demands of some starched-shirt-and-power-tie-wearing guy with an M.B.A. into code.  We understand information as well as anyone -- because we understand how information needs to be ordered in order to be processed and stored efficiently.

That's why they call us "analysts," right?

financial programmer
Wednesday, June 12, 2002

Ahiem Gentle People,
Just to add my two bits...
C.P.A's are actually very clueless!!!
I know. I lived with one for 4yrs, and I mingled with her "CPA" friends.

When I say clueless, I do mean it in a generous sense
of the word.
It's actually sort weird, they mostly visually look good/great.
For some strange reason society seems to have hardwired into our brains(developers), that what looks visually good
must obviously be extremely competent/together.

Just think book keeper in stylish suit and tan,and you're
on the right track.

Why do you think they drink so much?
Seriously....

[
The irritation arises because sometimes the users -- even the bigwigs, the C.P.A's who run the department -- are not exactly sure what the business process is. Maybe the business process is very messy. Maybe certain decisions will have to be made in order to nail down the business process, remove its messy edges, so that it can be translated into code.
]

Doug G
Thursday, June 13, 2002

"That's why they call us "analysts," right?"

I've always believed so.  There are many people like your co-workers out there... taking the dictates and implementing them.  When it doesn't work out, then they always say "but the user didn't tell us that".

Users don't know what they want, but they will know it when they see it.  To implement an effective automated business process, you have to look through the users eyes.

Expecting the user to do the design of the system is denying the responsibility of the IT professional, regardless of title.

No, we are not drones, nor are we slaves.  And sometimes you do have to TELL them what they need, despite what they say they want.

Joe AA.
Thursday, June 13, 2002

Users don't know what they want.

Users only know what they DON'T want AFTER they've seen what you've given them.

For this reason, I am a firm believer in rapid prototyping using models and simulations to help minimize the risk as early as possible.

I don't think this is any different from any other type of design field.  I wouldn't build a bridge for somebody without letting them see a little model of it first.  "But this bridge can handle 100 cars an hour.  What do you mean I can't pack the cars that tightly?  You never told me that when we started."

William Frantz
Monday, June 24, 2002

*  Recent Topics

*  Fog Creek Home