Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Confessions of an Unrepentant Code Commando

By localroger in Op-Ed
Sun Mar 10, 2002 at 01:57:53 PM EST
Tags: Software (all tags)
Software

Not long ago, Kalani asked me in a deeply buried comment what I thought of this article by David Thielen. It's a good question, and it deserves a more thorough response than I had time to give when it was posed.


In case you have any doubt, I advocated the commando approach, fighting the good fight for programmers to be able to do their own thing
...
I was wrong and Larry was right. (Boy, that hurt!)
-- David Thielen
If you think of coding in military terms, there is an exactness to the phrase code commando. There is a reason Thielen did not style himself a code jarhead. Commandos work alone or in small teams; they are highly skilled; they do dangerous missions where backup is unavailable; and in many cases they, not their commanders or comrades, take ultimate responsibility for failure.

Commandos can do what grunts do if they have to, but they don't like it; they are better than grunts, they know it, and they act like they know it. (If you've ever known a bona fide Green Beret or SEAL, you know what I'm talking about.) Grunts, whether alone or in arbitrarily large groups, cannot do what commandos can do. That's why the military goes to great expense to create such people, even though they are a pain in the ass to work with.

Code Commando Boot Camp

In the military, commandos go through special training. Code commandos will be quick to tell you that the usual educational channels will no more make you a code commando than standard boot camp will make you a SEAL.

The code equivalent of commando training usually involves a primitive computer, a daunting task, and a large amount of unpaid time. The task may involve reverse-engineering a large amount of undocumented code, or fitting 27K of application into 16K of RAM. The budding commando immerses himself not only in the machine and task at hand, but in every manner of skill even remotely connected with it. He tries many things that do not work. One day, if he does not wash out and give up, he will receive the epiphany by which all code commandos come to first awareness:

Computers really aren't all that complicated.
By corollary, there is no such thing as a "hard" language, since all computer languages are more or less the same (give or take a few minor strengths and weaknesses). There is no such thing as a large task, if you break it down into fine enough pieces.

It is hard to overestimate the importance of this. The code commando doesn't understand this as a theoretical platitude; he has lived the truth of it. It's easy enough to assert that, with a modest sustained effort, you can walk from Los Angeles to New York; it's quite a different thing to have done it with your own actual feet. The code commando has walked the walk and he feels an easy (and sometimes ill-considered) contempt for the code wussies who have only watched it on TV.

Code Commando Limitations

Commandos can't do everything. The team that can blow up a bridge behind enemy lines cannot organize something like the D-Day Normandy invasion.

This seems to be the basis of Thielen's reverse epiphany. "Modern projects" (his phrase) are now too big for the commando approach, and techniques are now well-formed enough that the commando's ability at field improvisation isn't necessary. The commando's strength becomes a liability, since the on-the-fly changes he makes to his part of a project sabotage his neighbor, who is relying on the API to work as specified for his code to work.

This is a legitimate point, one Thielen makes with an air of apology. Yet he also makes several points in favor of the commando approach:

  • "I still believe the best team size is two or three people."
  • "Nothing can make up for having poor programmers."
  • "I have yet to see CASE tools do anything other than slow down a project."
  • "It is also crucial that you give programmers ownership of the pieces on which they are working."
  • "Closing off windows, requiring set hours, enforcing a dress code, and supporting other stupid human resource edicts can also contribute to lower productivity."
What is going on here, it seems, is that Thielen himself has gone up the ranks; once a successful commando, he now wears a general's bars and has been asked to organize D-Day style invasions. And yep, he's found that you can't use commandos for that, any more than you eat soup with a fork. You have to use grunts, and if you have to write the directions for them in comic book form, then you deal with it.

The hidden assumption in this is that all programming now consists of these million-LOC super-projects and that the commando has outlived his usefulness. I would dispute this on several fronts.

The Myth of the Small Project Demise

I have worked for the same company continuously since about 1985. For most of that time I have been programming; at first as a sideline to my "real" job as a service technician, then for the last 13 years or so full-time. In that time I have completed over 2,000 separate projects. Most of these have been sub-1KLOC quick hacks. There is a constant demand for this work because there aren't many people who can do it right. A lot of little industrial devices come with their own pidgin control languages, but not many people can write programs for them which work reliably and (more importantly) fail gracefully when something goes wrong.

At the same time I've done some projects that are very large, to a one-man shop such as myself. I've done front ends liaisoning with customer mainframes, including several AS400's and a couple of enterprise-level SQL databases. I've done real-time systems doing plantwide data collection. I've done high-speed classification and complex statistical reporting. And I've done it all in the classic commando form. I have delivered several projects very late, I will admit, but I can count the projects for which we weren't paid on the fingers of one hand. And I have had exactly one project which failed to work, after management insisted I use a piece of hardware I warned them was inappropriate. That was in 1987. Fortunately, our choices aren't as limited today.

If the small project was dead, I would be on the unemployment line instead of quoting deliveries in 2004 for people who are willing to wait.

What I have often found is that the small-project front end is more reliable than the big-project database it's fronting for. The myth is that my kind of work is being obsoleted by "everything" systems like SAP which integrate everything from the shop-floor user interfaces to the drill press controls and the accounting database into one overarching package. The truth is that the end-user companies who try to implement such systems keep coming back to me for bits and pieces they know will work.

If the code commando isn't an appropriate soldier for the big project, then it must also be said the big project isn't an appropriate tool for many real-world problems. The big project has inherent limitations; it is never as reliable, the user interface is never as smooth, and it is much harder to update when a problem surfaces. These aren't reasons to retire the code commando, though; they're reasons to question the deployment of big projects in places where they aren't appropriate.

The Sloppy Commando

Because the training for code commandos isn't formalized, we tend to pick up a lot of bad habits along with the First Epiphany. We develop language and platform chauvanisms, and fail to document things we consider "obvious." Code commandos who have these faults can still accomplish amazing things, but it's correct to criticize their shortcomings.

Code commandos who actually work in commando style generally reach the Second Epiphany within a few years:

YOU ARE FALLIBLE. You must take certain precautions because of this.
It's the military equivalent of being asked to lay out a minefield, then to pick your way through it a year later; not too easy if you've forgotten where the mines are. If the code commando's style is forged in the cauldron of an impossible project tackled and conquered, it is tempered with the stink of failure. One day the budding commando looks back over a chunk of code written a month ago and scratches his head -- What fool wrote this crap? Oh wait, I wrote it! Or he utterly fails to follow the "obvious" logic which he didn't bother to document. One way or the other, he realizes that he must comment his code and follow some conventions so that he and others can understand it later.

Writing really bad code is an occupational hazard of being a commando; what Thielen seems to have forgotten is that it's a necessary part of maturing into your vocation. If owning your own code gives you a heady sense of independence, you must also be prepared for the personal stigma of failure when that code fucks up. You can't lay it off on the team or the manager. It's yours, buddy. You get to fix it and wipe up the mess while everyone looks at you.

Back in 1989 I wrote a program with a bug in it. (Hard to believe, huh? :-) What happened was that the cover of a 20-ton baling machine closed while a sheath used to guide falling product was still in the "down" position. This resulted in two very expensive pieces of metal being forced to occupy the same physical space by a ram strong enough to crush a car. The end result was that I had to watch for an hour as five very tough plant workers whaled away on the sheath with sledgehammers to bend it back into shape. All because I made a mistake.

Things like that are why I am just a little less tolerant of sloppy code than most people.

Thielen says this about the code commando:

Without up-front architecture and design, you are almost guaranteed to write code that, as you progress, cannot do what you need it to do.
That's very true. But it's not a limitation; the code commando gets used to rewriting code. You get used to doing whatever it takes to make it work. That takes time and, often, rewriting. The problem is that rewriting is bad in the context of a large project, because it interferes with what the other coders are doing.

The Myth of the Big Project

There is no such thing as a million-LOC project, or even a thousand-LOC project. If you have something that looks like a single task with this kind of line count, what you have is a bad specification, which you should change. But in a big project, you can't do that...

A perfect example is the Windows API. It is chock full of really bad specifications which couldn't be changed once written, so they are only half-implemented or worse implemented plain wrong. There is no mechanism for some guy in a cubicle at Microsoft to say "Now that I'me coding this function, I realize three of the seven specified error messages are almost never used and one of the arguments is both unnecessary and a pain in the ass to deal with." He can't do that because six other wonks in cubicles are coding other functions which use the API whose deficiencies he has just discovered.

What seems to happen at Microsoft is that this guy calls the other six wonks and says "Do you really need _____ to be implemented?" and if there is a consensus, he quietly omits to support the API as written. This is the worst of all possible worlds, for obvious reasons. It's also inevitable when you over-specify projects from the top down.

The Windows API is plagued by too many error messages which must be laboriously checked, too many arbitrary command parameters which may or may not be supported in real code, and too many conflicting and arbitrarily chosen ways of doing the same thing. There is nobody in a position to say "We're going to decide once and for all when to use variants and when to use strings, and change everything to make it consistent." Contrary to popular belief, the Windows API is not so huge it can't be understood by a single person; it's only a few dozen pages and there are a modest number of functional groups. It's only such a pain to deal with because there are so many exceptions, so many rules not followed.

While it's true you need specifications to hold a large project together, you shouldn't need to slavishly follow specifications which, at coding time, can be shown to be stupid. This is why you code from the bottom up, not the top down, and you build your more abstract specs from proven building blocks.

I have never seen a project so large it could not be broken into small chunks -- say, 100 lines of code max. However, in the process of subdividing a project you often run into broken specifications which can't be handled without byzantine exception handling and other tricks which keep your chunks large. The code commando would rewrite these broken specifications, but the coder on a large project can't. This is not a problem with code commandos; it is a problem with the handling of large projects.

In the original discussion, I made this comment:

If you make your bricks strong enough, you don't need to worry about the architecture of your dome.
I stand by this comment. If you build a dome of masonry, you need to heed the loading of your bricks and mortar, and build it carefully so it's supported during construction. But if you weld your dome together out of steel plate, or fire it as a monolithic ceramic construction, you can lift it up bodily and turn it upside-down without compromising its integrity. You don't have to pay close attention to its exact shape, and you are freer to indulge in artistic whimsy.

It's the same with code. Make your blocks small enough, strong enough, and solid enough, and the larger blocks you make with them will inherit their strength. You can do this from the bottom up through as many layers of abstraction as you need, and build arbitrarily large applications that will not crash or fail no matter what you do to them.

When you do this you can't dictate the exact shape of the final product at the outset, though, because you may not know what kind of bricks you'll end up with in the high layers of abstraction. This kind of programming involves as much exploration and discovery as it does imposition of order. You can work toward a final goal, but you may not end up with exactly what you expected. You can only be sure you will end up with something that will do what it can without falling down.

The Myth that it's Not Important

Industry is different from Web design, so I'm occasionally reminded. My code can destroy hardware and kill people. You don't have to be as careful in other venues, where the economics are more important.

To which I say: tell that to the people who use that other software.

Large sloppy applications like Windows and SAP are increasingly found doing things that are life-threatening and mission-critical, such as controlling emergency dispatch systems, automatic teller machines, and maintaining medical databases. (see just about any issue of the Risks Digest.)And as a user I resent the hell out of software which assumes I can be bothered to periodically reformat my hard drive or be denied access to services because the authors couldn't be to do their jobs right. When I talk to non-programmers about this they always agree; it's not that they don't care, it's that they don't realize there is an alternative.

Customers want software that works. When they get it, they like it better than software with more features, snazzy graphics, and automatic background functions. It doesn't matter how "smart" the application is if it's down half the time, or if you can't depend on it doing what you've told it to do.

In my career I have often delivered programs that differed markedly from what was discussed at design time. I never provide screen shots, since I tend to tweak the layout of user controls right up to the last minute. I have omitted functionality which I felt compromised my software, but more often I've added functionality not asked for because it was so easy. I have never had a complaint because of this. Quite the opposite; I'm sought out precisely because I'm willing to go the extra mile to make a system that's robust and easy to use.

I have called customers about mainframe interface API's and asked to rearrange data; I've never been refused. End users don't care whether a system exactly matches the specification; they care, very deeply, whether it works. Often a form layout or tab-order makes the difference between a system that is a pain in the ass and one that makes the work day breeze by. I like to tell customers that "the hard part of my job is making your job easy." If a customer has cause to notice the quality of my work at all, it probably means I've done something wrong. The best software is invisible to its users.

Like the other kind of commando, I'm most successful when you never realize I was there.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o this article
o the Risks Digest
o Also by localroger


Display: Sort:
Confessions of an Unrepentant Code Commando | 106 comments (98 topical, 8 editorial, 0 hidden)
hard language (3.85 / 7) (#1)
by zephc on Sun Mar 10, 2002 at 11:43:40 AM EST

there is no such thing as a "hard" language

have you seen Brainf*ck? =]

LOL -- I can deal with that (2.33 / 3) (#5)
by localroger on Sun Mar 10, 2002 at 11:57:54 AM EST

Actually, Brainfuck is almost English compared to some Forth-like TIL's I once hacked around with, let alone a certain controller macro language I could name *cough*GSE*cough* which is roughly as readable.

I can haz blog!
[ Parent ]

Unlambda is much nicer than Brain**** (3.00 / 2) (#10)
by i on Sun Mar 10, 2002 at 01:33:02 PM EST

And it has solid theoretical underpinnings! Once I'll make a lazy version of it :)

and we have a contradicton according to our assumptions and the factor theorem

[ Parent ]
the possibility of a truly powerful language (3.00 / 6) (#12)
by lazerus on Sun Mar 10, 2002 at 02:25:17 PM EST

went out the window when FORTH failed to gain acceptance. Scince most system-level applications are now written in the New Jersey-style "C" and bloated "C++" languages, you can pretty much be assured that any project larger than a few thousand lines will be infested with bugs and memory leaks. Have a nice day.

[ Parent ]
Malbolge (3.50 / 2) (#13)
by CaptainSuperBoy on Sun Mar 10, 2002 at 02:29:52 PM EST

One word: Malbolge

From the site: Malbolge was truly created with the idea that programming should be hard. It should be as close to the Infernal as a programming language possibly can be.

--
jimmysquid.com - I take pictures.
[ Parent ]

hard language (none / 0) (#65)
by ethereal on Mon Mar 11, 2002 at 01:00:49 PM EST

And also, apparently, the idea that web pages should be almost impossible to read :)

--

Stand up for your right to not believe: Americans United for Separation of Church and State
[ Parent ]

whatever (1.96 / 29) (#6)
by turmeric on Sun Mar 10, 2002 at 12:39:54 PM EST

you are a computer programmer. you are not a military commando. there is almost nothing the same, except if you watch too many movies. give me a break.

Re: Whatever (4.75 / 4) (#7)
by akharon on Sun Mar 10, 2002 at 12:50:23 PM EST

He's not saying he can sneak behind enemy lines IRL, he's saying that he's the kind of guy that you can stick on a difficult task, and if that task is remotely possible, he's the guy to do it. You'll find these kind of people in just about any industry, just under different names.

[ Parent ]
Dude, it's an analogy. (4.33 / 3) (#18)
by magney on Sun Mar 10, 2002 at 03:07:34 PM EST

Most of us are capable of distinguishing between a job that requires hard physical labor, and occasional but prolonged bouts of being in imminent and severe danger of dying while having at the same time to put other people in the same sort of danger - and a job that requires sitting around in an air-conditioned/heated office and thinking a lot.

And no one, least of all the author, is actually comparing a programmer to a soldier. The point of the article is to compare two different kinds of programmers and suggest that the difference between them is similar to the difference between two different kinds of soldiers.

A:B::C:D doesn't necessarily mean that A and C have anything to do with each other.

Do I look like I speak for my employer?
[ Parent ]

what? (2.20 / 5) (#48)
by turmeric on Mon Mar 11, 2002 at 01:25:06 AM EST

that is all true. he could also say that he is a certain type of programmer just like there are certain kinds of whores. he is the whore who will do piss fantasies tied up while the john does lines of coke off her crotch, while most programmers are like high class escort girls with full page ads in the new york city phone book.

Or he could be the janitor who has to clean up the stall when some brilliant harvard law student decides to drop a 'shit bomb' over the side of the toilet and lay a gigantic jackson pollock in shit all over the floor. and then there are the janitors who wax and mop the halls.

Or he could be the office secretary who goes out for the bosses lunch and buys his wife presents, instead of the secretary who has to sit and type letters all the time.

Or he could be the guy cleaning up the ball park who has to clean up the chewing gum, while another guy organizes cup cleanup.

etc etc etc.

[ Parent ]

The Tao of Programming (3.66 / 3) (#14)
by infinitera on Sun Mar 10, 2002 at 02:40:41 PM EST

Cool article, and while I haven't exactly digested all of it, it did remind me of something else cool. :)

Experience the Tao

(That's just the first version I saw on google, ones formatted differently existed, but that one is pretty)



-Dan

Wow. (3.00 / 1) (#46)
by bakuretsu on Mon Mar 11, 2002 at 01:19:43 AM EST

That is probably the most insightful, entertaining, and thoroughly satisfying thing I've read since The Acts of Gord. Thank you!

-- Airborne
    aka Bakuretsu
    The Bailiwick -- DESIGNHUB 2004
[ Parent ]
Old (none / 0) (#66)
by ucblockhead on Mon Mar 11, 2002 at 01:03:10 PM EST

That originated as a dead tree book.

I've had that on my desk ever since I started my career.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]

Once again, amazing. (none / 0) (#67)
by bakuretsu on Mon Mar 11, 2002 at 02:22:32 PM EST

I should go pick myself up a copy, I think everyone even remotely involved in programming should have one. I can see myself quoting the Tao in certain situations.

-- Airborne
    aka Bakuretsu
    The Bailiwick -- DESIGNHUB 2004
[ Parent ]
Books (none / 0) (#68)
by ucblockhead on Mon Mar 11, 2002 at 02:25:19 PM EST

It's series that includes The Zen of Programming and Programming Parables. But the first is the best.
-----------------------
This is k5. We're all tools - duxup
[ Parent ]
In between (4.00 / 1) (#16)
by CaptainSuperBoy on Sun Mar 10, 2002 at 02:46:01 PM EST

My position is probably between yours and Thielen's although I agree with you on most of the points. My company does great work - we are a tiny programming firm with clients mainly in industry, manufacturing, retail. They are small-to-medium sized businesses, and they don't care about use cases, class diagrams, or white-box testing.. they care if their software is delivered on time and if it works. So we deliver.

I'd put us squarely on the code commando side.. for us it does save time and costs. You are dead right about the myth of the small project's demise. I'd say our typical project is up to 5 kloc. It's deadly to overspecify and lock yourself into a design, when you're interfacing with a machine and you don't have the final API.. or when you're coordinating with another vendor and you see that their API has giant holes in it. And yes, sometimes you have to accept that project from the customer who has no idea what they actually want. Part of the job is bringing them ideas and throwing away the parts they don't want.. you could re-write several times in that kind of project.

However, things just aren't going to stay that way. You mention SAP and Microsoft.. as SAP and, say, Great Plains, mature and become more flexible, companies will be able to hire an in-house IT guy to hack together a system that meets their needs, rather than contracting for a shop-floor system because "the big guys just don't offer what we want." The future is the big project, a project that demands a higher level of design and specification.

It's hard to say this, being a small software developer, but I really think that our industry will be unrecognizable in 10 years.

Thank you for the extremely well-written and thought provoking article.

--
jimmysquid.com - I take pictures.

Real Programmers (1.85 / 7) (#19)
by wiredog on Sun Mar 10, 2002 at 03:20:53 PM EST

Use assembly, and have programmed bare metal in machine language.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
Real Programmers (4.75 / 8) (#24)
by bodrius on Sun Mar 10, 2002 at 04:42:12 PM EST

HAVE used assembly, and MAY HAVE programmed bare metal in machine language (by which I guess you mean Hex/Binary/Decimal-If-You-Must opcodes and no mnemonics).

Real programmers have done that at some poin in their life. Real programmers are able to do that again if they must.

People who keep doing that when they don't have to are not "Real Programmers". They're idiots.
Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]
Every programmer (3.00 / 1) (#29)
by wiredog on Sun Mar 10, 2002 at 07:28:53 PM EST

should do those sorts of things at least once. I really appreciate the clarity and ease of use of languages like C.

Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
[ Parent ]
C? Clarity? (3.00 / 4) (#35)
by Delirium on Sun Mar 10, 2002 at 08:18:24 PM EST

should do those sorts of things at least once. I really appreciate the clarity and ease of use of languages like C.
Bwahaha. Only an asm programmer could convince himself that C is high-level. =P

[ Parent ]
C and asm (4.00 / 1) (#56)
by Betcour on Mon Mar 11, 2002 at 05:16:32 AM EST

C is more like assembler with macros than a high level language. A real high language wouldn't force you to use pointers or treat strings as array of chars. As for weak types, I have no problem with that as long as there's still some limits on it (casting a char into a byte is fine and should be allowed, but casting an int into a pointer should be totally fordidden and allowed under no circonstances).

Now C++ can be a totally different beast of course (and quite one !)

[ Parent ]
real programmers (5.00 / 2) (#73)
by DavidThielen on Mon Mar 11, 2002 at 03:08:52 PM EST

Hi;

I loved your line about "People who keep doing that when they don't have to are not "Real Programmers". They're idiots" Very true.

On the flip side, as one who has programmed in assembler a lot, written a C program that created machine code on the fly and executed it, and wrote some of the original disk drivers for WIndows 95, I don't think real programmers need to have ever seen assembler or C.

I know several brilliant programmers who only know Java. The trick isn't what tools you know, it's can you design and code a good solution for a problem using appropiate tools.

- dave

ps Chris Hecker once wrote a C transparent bitblt function that was faster then the optimized assembler one every game developer was using at the time. He did it to prove that it's the algorithm, not the tool that matters.

[ Parent ]
Let me guess (none / 0) (#85)
by Ken Pompadour on Tue Mar 12, 2002 at 12:07:37 AM EST

It stored run lengths with a flag identifying either 'nothing,' 'totally opaque,' or 'varying transluency'?

...The target is countrymen, friends and family... they have to die too. - candid trhurler
[ Parent ]
Wow, where to begin? (4.33 / 9) (#20)
by Kalani on Sun Mar 10, 2002 at 03:28:00 PM EST

Well firstly, I really wish you'd have emailed me or something so that I could have prepared a more suitable immediate response. As it is I came here without having slept in 24 hours and I spit coffee all over the place when I saw my name on the front page.

If anyone is interested, the thread (in full) that localroger mentioned is here.

Now on to some specific points ...

I think that the specific message of Dave's little speech here is that more sophisticated methods of organization are necessary as projects grow in size. You'll notice that he acknowledges that there are some projects that are small enough to still be one-man operations, but the main thrust (I think) is that the tasks that most programmers are faced with have grown in size and complexity over time. Also keep in mind that he wrote this in 1999 and that at the time he was probably drawing heavily on work at either Cyrix or Global Commerce Systems (if there are any healthy skeptics out there who want to know what sort of projects he's worked on, you can find his resume here -- check out the hamburger commentary while you're there). Also keep in mind that even commandos are part of a larger system. You can have commando-style projects within the scope of a larger system if the commando just conforms to a specific programming interface for teams that use his work (e.g.: writing a serial port driver).

Also localroger, your comment about refactoring and such isn't applicable in the context of the growing project that Dave is discussing here. If you, as a lone programmer, are developing a palmtop OS, the constant refactoring approach will cost increasing amounts of time as larger parts of interrelated portions of the code need to be refactored. In some cases I've seen differences as extreme as the differences between linear and polynomial time implementations of algorithms (which would also explain the small interval of dominance for commando coding over strategic coding in small projects).

The Windows API is reasonably systematic if you stick to the most recent parts. To answer your example about variants and strings: variants are used where types are ambiguous (IDispatch method invocations, generally used by "untyped" languages like VB/VBScript) or when any type is valid -- and even then variants are an aspect of OLE/ActiveX only. Yes, there are amusing inconsistencies in programming interfaces -- like the fact that you still manage windows and drawing objects by handle but you can get a system IMalloc pointer to allocate managed blocks of memory for you (and indeed you need to use such an object when working with certain shell functions).

On your "the myth of" sections, you are also getting into a bit of "specification semantics." The process of breaking a large project into "small chunks" is what systemization is all about. Subsystems, plugin interfaces, base class standards, message multiplexers, protected memory, cross-process/thread communication/synchronization and extensible script interpreters are all examples of constructs that have been invented at least in part to aid in the *delineation* of boundaries between small tasks in large systems. This is an important distinction because breaking the huge problem into many tiny sub-problems is only part of the solution. Defining the joins between all of those sub-units is a task in and of itself (perhaps even a large task that is further refined etc).

In any case, your closing line suggests to me that you have only your users to answer to. The whole idea behind moving beyond commando coding (and I only speak for my own sleep-deprived imaginings of what my uncle envisioned with this whole thing -- I by no means speak for him) is that you're answering to other programmers or to project managers (project managers who know to say "has the billing driver manager been implemented yet?" rather than "could you reposition those tabs, I like them better on the side?" when the issue is really one of infrastructure).

Also, I've never talked to Dave about this so please, again, remember that I do not speak for him here. He's vastly more experienced in programming and in managing programmers than I am (in fact I have had to manage no programmers aside from myself).

Hopefully this doesn't all come off as very muddled but I've been awake for a really long time without sleep and I felt that this story demanded an immediate response from me. I'll try to respond again when I'm a bit more conscious.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
Sorry if I blindsided you (none / 0) (#43)
by localroger on Sun Mar 10, 2002 at 10:50:54 PM EST

I've actually been picking at this piece since the original discussion, and since I finished it today I wanted to post it, because I'm out of town through at least Wednesday. I just wrote a reply to David, and after this I probably won't see this thread again for a few days myself.

If you, as a lone programmer, are developing a palmtop OS, the constant refactoring approach will cost increasing amounts of time as larger parts of interrelated portions of the code need to be refactored.

Obviously, there is a talent to writing "bricks" which will be useful and not need refactoring. Experience reduces the incidence of this. It also helps if you can hold the whole project, or at least a whole vertical thread from lowest to highest level of abstraction, in your head. This is not as hard as it sounds if you practice at it, though it seems very hard when you first start out.

This is an important distinction because breaking the huge problem into many tiny sub-problems is only part of the solution. Defining the joins between all of those sub-units is a task in and of itself

Frankly, IMHO if you have trouble figuring out how to break up the problem, you're working in the wrong direction. You build up the subparts that are obvious, and let the joins define themselves. This is a perfect example of how over-specifying from the top down breeds unnecessary complication. You may have to "play" with joins but here you're refactoring small code items which can be refactored quickly. Once you get an abstraction layer done, you are finished with it -- if you've done your job right, which gets easier with experience, you won't have to refactor down to a lower layer that you've tested out and signed off. You may, however, find your project drifting away from the implementation you originally envisioned, and my approach is to let that happen. Obviously I can get away with that, while others in different situations can't. Oh well.

In any case, your closing line suggests to me that you have only your users to answer to.

The users are the only people who are important. Users determine whether the bills get paid (at least, if their managers are doing their jobs). If I have to work with Fred and Fred is a corporate spec drone and we have constant fights, it matters not one bit if we managed to put together a product acceptable to the customer; we will get paid. If we agree on everything and work together as smoothely as teflon it matters not one bit if we can't deliver a project that works in an acceptable time frame. If we don't get paid, it doesn't matter why when it comes time to write our paychecks.

There is an instructive little aphorism I tell people at work to illustrate my priorities. The salesman throws the party when he gets the P.O. The service department (roughly including me) throws the party when the installation is complete and functional. But the comptroller doesn't throw the party until the check clears.

I have trained myself to gauge my performance by how happy the comptroller is, and recommend to my coemployees that they try to do likewise.

I can haz blog!
[ Parent ]

It's OK, but I still haven't slept ... (5.00 / 1) (#49)
by Kalani on Mon Mar 11, 2002 at 02:16:36 AM EST

... I've had to do a lot today and I'm so completely exhausted that it's difficult even to explain how exhausted I am. :)

Still, I think I can address some issues that you've brought up here (and forgive me for not fully addressing everything in your op-ed in my original post -- I really do intend to do that tomorrow or whenever I get some rest).

First of all, for all of the effort spent on Dave's analogies you might want to take a look at some of his code: Source from "No Bugs!" | Source from "Writing Windows Virtual Device Drivers" | Some random pathfinding code I found on his site.

I looked through some of his code samples briefly and I'm sure that if you go through them you'll see that the heaviest emphasis is not on comments but general structure (also, two of those zips are companion files for two of his books -- if they're at all interesting to you then you might want to check the books out).

On to your post to me ...

Obviously, there is a talent to writing "bricks" which will be useful and not need refactoring. Experience reduces the incidence of this.

So does prior planning reduce the incidence of refactoring. If your brick analogy here is the same as my "basic atomic types" from the OTHER thread (this conversation is really all over the place) then yes of course it's very important to rigidly define these things and make sure that you have tested them very well before integrating them into the main application (or applications). However, that is not all of code design (nor is it all of implementation ... and I'll cover this in more depth in another part of my response below).

It also helps if you can hold the whole project, or at least a whole vertical thread from lowest to highest level of abstraction, in your head. This is not as hard as it sounds if you practice at it, though it seems very hard when you first start out.

Respectfully sir, you've said yourself that you aren't writing 1MLOC programs. Although I do not doubt your intelligence, everyone has a finite capacity for storing things in their minds. I also have written 50K-100KLOC programs and have been able to generally keep the whole thing in my head, but that's pretty near the breaking point. There are many projects that are practically impossible to keep in your head ("practically" because even if you did hold the monolithic thing in your mind, you'd spend too much time juggling it all around in your head -- there is a limit where that happens).

IMHO if you have trouble figuring out how to break up the problem, you're working in the wrong direction. You build up the subparts that are obvious, and let the joins define themselves.

Of course if you have trouble breaking up the problem you need to spend more time on the planning (and research perhaps) stage. However, the joins (keeping in mind the context in which I introduced that term) do not take care of themselves. There are many examples of this. Some research team (and this may be an urban legend, I can't even recall who told this to me) thought that intelligence would emerge from any sufficiently complex system -- and so they threw a whole bunch of complex electronic components together and waited for HAL to emerge from the electromagnetic ooze (which obviously didn't happen). Another example is the fundamental types of Adobe Photoshop. You can have abstractions of multi-layered pixel canvases integrated with abstractions of whole classes of graphical effects housed in external libraries and lots of little mini subsystems to direct painful things like color management, but those "bricks" do not come together to form Photoshop. There is an essential "non-brick" essence that operates above the fundamental types and allows the user to directly or indirectly control them. This is partially why all of us programmers haven't been replaced by a shiny pile of DVDs (it's also that all of the atomic types for all of the programs that we'll need have not yet been written).

You may have to "play" with joins but here you're refactoring small code items which can be refactored quickly.

Yes I agree in most cases (and in fact this is the case that I think we were discussing on the other thread especially). The trouble is that not all programs are high-block low-join ... there are many that are low-block high-join as well. I have a friend named Fred who worked on the water-filtration system on the ISS as a contractor from Boeing (water-filtration=urine-recylcling). He told me about a number of problems (many of which I've forgotten for lack of use) that involved thousands of different uses for a relatively small set of distinct atomic data elements (one detail I do recall is his description of the redundant systems he built just to handle input from the wings and tail). Hmm, maybe I should continue this particular line of thought after I get some rest.

You may, however, find your project drifting away from the implementation you originally envisioned, and my approach is to let that happen. Obviously I can get away with that, while others in different situations can't. Oh well.

Right, well that would affect both of our strategies greatly and to different degrees then.

The users are the only people who are important. Users determine whether the bills get paid (at least, if their managers are doing their jobs).

What I said was that you answer directly to users or to technical staff. In one case you're part of a team that is, to the extent of actual technical details, responsible only to itself. That's the distinction that I was making and I think you're either making a different point here or ignoring mine. The rest of the stuff about group dynamics is true, but not the point that I was making. My point assumed that your engineer partner knew what he was doing and that you could work together. The details of what goes on between the two of you to lessen the amount of time you've got to spend on non-core issues is a whole other (MASSIVE) issue.

I have trained myself to gauge my performance by how happy the comptroller is, and recommend to my coemployees that they try to do likewise.

That's all very insightful but it doesn't have a lot to do with the sort of long-term large-scale development issues that my uncle's article brought up. It almost seems like you're advocating speed and (what are essentially) frivolities over long-term quality (ar, we should talk about code rot but it's late and I'm so tired already).

Anyway, I'd better (finally) get some sleep. I'll try to come back within the next day or so to address other points you raised in the parent op-ed piece.

Thanks.

-----
"I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
--Richard Feynman
[ Parent ]
In case anyone missed it (3.66 / 3) (#21)
by cooldev on Sun Mar 10, 2002 at 03:35:08 PM EST

This is the discussion that led up to this story.

Lots of good comments from both sides, IMHO, and I don't have time to repeat them all here. :-)



Myths & change (4.37 / 8) (#22)
by obsidian head on Sun Mar 10, 2002 at 04:28:16 PM EST

I haven't worked on large projects before, just small and medium ones. (Medium being something like a 30-person overall team creating software for graphic designers.) But I have studied this topic a lot, and know people working on them.

  • In large projects, a spec is a messy high-level language, and you pay people for the monkey work of implementing it. The spec is what you likely want the commandos to write.

    In Mythical Man-Month, Brooks talks about his multi-million dollar mistake, choosing a 150-person team of normal programmers over a small 10-person team of commandos, to write the spec. He had been warned that the 150-strong team would take just as long as the commando team, and it wouldn't be of as high quality. Well, in the end he chose the large team, and their work was indeed late and not as cohesive as a smaller team's would be.

    So, is it the death of the commando, or is the commando just doing different things now?

  • That second epiphany, of being fallible, I think is the wrong lesson. You have to forgo that lesson, no matter how tempting it is to give in, because it's better to have an epiphany everytime a mistake is made, and let it be the cause for some soul-searching.

    Mistakes are made on purpose. Perhaps you didn't automate something you should have, or didn't let yourself stop and consider. But any mistake in the code is just put there, and you have to understand why you did it.

    You talk about various chauvinisms, and areas where commandos don't really question themselves. But in this case, I'm just plain right.

  • For what it's worth... (none / 0) (#63)
    by dennis on Mon Mar 11, 2002 at 12:57:06 PM EST

    I work in a team of 3 programmers. We have a website that doctors' offices use to do eligibility checks, referrals, etc. Our design process consists of having a meeting, agreeing on an approach, and picking someone to do it. We crosstrain when we have time but basically, we each have areas of the application we're responsible for. We meet every day so everyone knows what's going on, and redesign as often as necessary, sometimes to meet new requirements, other times because we just have a better idea.

    It seems to work - we've managed to compete successfully against similar products offered by companies a hundred times our size. Customers tell us our product does more, and is easier to use. I don't think we're really genius programmers, either. We're competent, we work hard, but we're all self-taught, using the same tools everyone else uses. For a while I was sure our giant competitors would crush us, but it just hasn't happened.

    [ Parent ]

    just plain wrong (none / 0) (#84)
    by DavidThielen on Mon Mar 11, 2002 at 11:33:14 PM EST

    Your comment:

    >>> ...But in this case, I'm just plain right.


    That statement alone would cause me to never hire you no matter what else you can show you've done. A closed mind is the last thing a project needs.

    - dave

    [ Parent ]
    Just plain irony (none / 0) (#87)
    by obsidian head on Tue Mar 12, 2002 at 12:18:20 AM EST

    Good thing you wouldn't hire me, in this case.

    I want the whole Peopleware workplace, and you wouldn't know that a chicken's lip was funny even if it bit you on the elbow.

    [ Parent ]
    The Microsoft Scenario (4.11 / 9) (#23)
    by cooldev on Sun Mar 10, 2002 at 04:39:29 PM EST

    ...is so funny I laughed out loud, but it's untrue. In my experience the causes for shoddy APIs are: (no holds barred...)

    1) Legacy. The APIs have evolved over a large number of years, during which part of the functionality has changed or become deprecated, but you don't have the luxury of removing or fixing it because thousands of applications depend on it.

    2) Developer with an ego and a bit of political power wrote it in the way it was easiest for him to write (vs. being easiest for people to use), and shuts down requests to have it fixed. One element of this is that old timers with deep experience in C and Win16 often have more say than the new hire with experience with Java and other languages with a decent API/object model. Luckily the smart developers recognize this, so some groups are worse than others.

    3) Adaptation to the Win32 API. Developers who work with the Win32 API all day for several years tend to craft their code in the same way because it's what they're used to.

    4) No single developer overseeing it. I've seen this happen several times: developers add functions and events to the public interfaces -- one at a time, and only as needed. As a result there's no conceptual integrity. The methods and events are non-orthogonal, vary in granularity, and the interfaces are incomplete.

    My opinion is that the root cause of at least 2 and 4 are Commando Coders, otherwise known as Cowboy Coders, Hotshots, and, yes, Hackers. These people come out of college knowing they can best most of their peers at coding, but unprepared for what it really takes to engineer quality software. Unfortunately the reward structure at many companies is set up to reward fast, highly visible progress instead of quality work, so their egos get reinforced. Often they're rewarded by the worst reward of all: They get to hack out the crap code, get hefty bonuses and pats on the back, and move on while other people clean up their mess.

    I've been on both sides of the fence (yay bonuses!), and sometimes it's apropriate to take the roll of a hacker (Commando Coder); quality hackers can be an awesome resource for building prototypes, testing tools, one-off releases, and isolated cool features, but it's best to not let them write the foundation of a shipping product.

    What's the solution? The solution is to take software engineering seriously. Everything else just falls out of that. Oh, and you have to have quality developers to start with, or you will fail.



    Woah there! Hold your horses for a sec! (4.66 / 3) (#30)
    by egerlach on Sun Mar 10, 2002 at 07:38:31 PM EST

    My opinion is that the root cause of at least 2 and 4 are Commando Coders, otherwise known as Cowboy Coders, Hotshots, and, yes, Hackers.

    Woah there buckaroo! Commandos and Cowboys are two completely different things! If you're equating the two then you're likely missing the definition of the Commando. Here's how I see the two:
    • Cowboy Coder (aka. Hotshot, Hacker) - Does his own thing. Can be given vague direction, but tends to do whatever he wants to. Doesn't heed much to criticism, because he likes his way best. Doesn't like to learn new techniques, because he trusts his old six-shooter. Yeehaw! It's good to be free!
    • Commando Coder (aka. Go-to guy, Hacker) - Trains until given a mission. Then completes the mission in the quickest and most efficient way possible, of course always keeping Quality as his top priority. If there is a spec on *how* the mission must be accomplished, it is followed, but improvisations may be made if the spec doesn't work. Understands the need for a command structure, but prefers to sit outside it. Will heed to criticism, but only if it is proven that the criticism is valid. Tries to stay abreast of new techniques to improve his skills. Calm, cool, and collected in the face of any problem.
    Big difference here. Now, Cowboy Coders often become Commando Coders after the Second Epihany that localroger describes... but some remain Cowboys forever.

    [Commandos are] unprepared for what it really takes to engineer quality software

    Again, a misinterpretation. Commandos do engineer, but they engineer at the small scale, and at that scale they do it well. Some Commandos move on to become Generals, engineering on a large scale, but some (like me) like to stay down in the trenches with other Commandos.

    If you think about those definitions I provided above, you should see the difference.

    "Free beer tends to lead to free speech"
    [ Parent ]
    Regardless (4.50 / 2) (#40)
    by cooldev on Sun Mar 10, 2002 at 09:14:22 PM EST

    Unfortunately most Cowboy Coders think they are Commandos. That's the problem.

    Drinking Game: One shot of Jose Cuervo for every self-proclaimed Commando Coder in this story and the comments. ;)



    [ Parent ]
    Jose Cuervo? (4.00 / 1) (#61)
    by punkass on Mon Mar 11, 2002 at 09:24:34 AM EST

    I'm sure that will contribute to quality coding...

    [ Parent ]
    They are all above average drivers, too! (none / 0) (#86)
    by cooldev on Tue Mar 12, 2002 at 12:12:57 AM EST

    What, haven't you ever heard of the Buffalo Theorem? Drinking kills off the slower, weaker brain cells, making the brain as a whole faster and stronger..

    The problem is there isn't an easy or quantifiable way to tell a Cowboy Coder from a so called Commando Coder as defined in the article until you've personally worked with them, and I seriously doubt that even 5% of the people on this thread saying "oh! I'm a Commando Coder" are significantly above average. If everybody and their sister is a Commando Coder it becomes just another development style/trend and looses it's implied meaning.



    [ Parent ]
    OK, fine... (none / 0) (#94)
    by buck on Tue Mar 12, 2002 at 03:31:41 PM EST

    ...not one line of code or documentation until the "engineers" give me a final, non-negotiable, irrevocable spec signed off by all parties involved. Oh, by the way, if you have an emergency problem, you're screwed since you have no design plan or anything.

    I don't mind giving up the role of "go-to guy". Just don't ask me to do anything beyond the spec.

    By the way, "software engineering" rates right up there with "object oriented programming" and "extreme programming". Just another buzzword used by people who sell & write books on it for a living.

    Time to get more H1-Bs.

    -----
    “You, on the other hand, just spew forth your mental phlegmwads all over the place and don't have the goddamned courtesy to throw us a tissue afterwards.” -- kitten
    [ Parent ]
    Development Philosophies and Evaluating Risk (4.00 / 3) (#25)
    by ikeaboy on Sun Mar 10, 2002 at 05:05:26 PM EST

    Development philosophies often miss or pass over the area of risk assessment... And in the end it all comes down to risk evaluation.

    Developing commercial software to make money is a straight risk-return exercise. In the early days of the web a lot of poor software was developed. However, since time to market was perceived as a massive risk, this wasn't an issue. When getting in first is all that was important (supposedly) having to refactor everything later is a non-issue. As such I now work on or with web projects today that are already having major legacy issues. This is often after only 12 to 18 months of being in production.

    As an example, I find that a large number of smaller companies I have done work for typically want an up-front fixed quote. All that this form of deal is transfer risk to the computer consultancy. Since risk travels uphill this doesn't achieve much. If they don't make the deadline, typically they fold or pull out of the project early. Either way everybody loses. I've found larger companies do not do this, although they will use their position to negotiate as hard as they can on every other point.

    If you want to reduce risk you can increase process, but this is just a risk reduction exercise, not a risk elimination exercise. There is always a risk, even if it is infinitesimally small. Specifying and testing everything to the very last detail basically amounts to reproducing the system many times over. i.e. Take a written spec to the greatest practicable detail and you get what amounts to code, and the same applies to testing. Specifications and testing are exercises to reduce risk; the amount that you want to spend on these areas should depend on the risk that you want to take.

    Take a programmer, get him to write code without any design phase you can still end up with a near perfect product. Chances are you will not, and it's a matter of deciding how much time spent on design/testing/etc will achieve the best result for the given risk. Even highly structured projects using strict development doctrines can fail (I've seen a number of failed Rational Process projects). However, generally that extra investment pays off, but at a cost of course.

    Commando and extreme approaches help break

    Often this is really a compromise, a process I find that people tend to find difficult. It generally tends to be too much risk or too little risk, typically because it's something people don't tend to think about. Additionally you can find team members (esp. technical and business) have very different views on risk, leading to incompatible approaches.

    Commando and extreme (etc) approaches tend to compartmentalise risk, giving project managers and sponsors a better handle on the risks involved. Failure and success is easier to manage and offset. For big projects this is extremely important.

    In the end I've found the greatest risk modifier are the people. Having quality people on a project is the best guarantee of all.

    That line is meant to be... (5.00 / 1) (#26)
    by ikeaboy on Sun Mar 10, 2002 at 05:08:41 PM EST

    Commando and extreme approaches help break... this process into manageable pieces.

    Must have slipped on a cut & paste.

    [ Parent ]
    Call them Barbarian Coders then (4.63 / 11) (#27)
    by DavidThielen on Sun Mar 10, 2002 at 07:16:16 PM EST

    Hi; As the person who wrote the original article, I was asked to make a comment here. So here goes. First, I think Commando Coder is a bad term. What would be better is Barbarian Coder. I use the term barbarian not in the maurading hordes, but in the cultures that came before the anvent of farming and technology. The Barbarian Coder is self taught and attacks problems straight on with no thought for the future. In history the barbarian many times did defeat the civilized opponent. But over time civilization totally crushed the barbarian. I personally bounce back and forth between managing (recently V.P. at a start-up) and coding (wrote a firewall at home over the last 2 months). So I have had the opportunity to see this from both sides over the last 20 years. And both sides throughout my carear, not just in management recently. And what I have found is that any development project will be completed by any developer quicker and with a better end result, if some basic practices are applied to it. This includes a 1 person one week job to a 2 year 50 programmer job. Now the smaller jobs can be accomplished with the barbarian approach. But that doesn't mean they can be accomplished better. And many times it's much worse. Let me give some examples: 1) The hero programmer. This individual, who generally is very smart and talented, can outproduce the other programmers. But he fights having a systematic approach to development because he can do it his way so fast. What happens is the company can never scale. As more developers come on, they can't write code that work's with the hero's code, because no one is sure what the other parts are doing. And the hero is god, so no one is going to "slow him down." And the company is limited by what the one hero can accomplish. 2) The cluster fuck. Take a group of talented programmers and throw them at a problem without architecting and designing it first. And they will each diligently implement their piece of it - to find that the pieces don't workj together, that parts are missing, that parts are duplicated. And it is a horrendous effort to get these parts working together. 3) Code it now, test it later. Without proper testing - FROM THE START - the code stays buggy. One bug is fixed and another pops up. Twenty testers are hired and they find so many bugs management gets even more upset. I don't care how good a developer is, without testing what ships will be crap. 4) It's just a little thing. Occasionally you do have a small project that nothing else will get added to. But it's rare. What's much more common is it's a little 2 day project. Then a 1 day project to add something, then another day a month later. The online store I did for my company was written this way. And now it's a mess. It takes me 4 times as long to fix and test something than it should. But the cost of rewriting it is prohibitive so I live with the mess. If I'd followed my own rules... but it was just a little 2 day project that I would never add to - yeah right. 5) Recoding is part of the business. Yes at times it is. But it's also a total waste of time when it's avoidable and that fact that sometimes it can't be avoided is no excuse for the times it can. I sometimes get mad at my kids when they screw up - but that's no excuse to get mad at them when something was not their fault. Here's my take on it. A lot of programmers are lazy and spoiled. They want to keep doing things the way they have been doing them. Learning to architect and design and unit test and properly comment is hard. So it's easier to say that one doesn't need to do that. But a professional programmer does understand that it's a necessary part of the job. That the small jobs are completed faster and better and the big jobs are completed this way. It doesn't mean it's enjoyable. But when I'm writing unit tests I just keep telling myself, 1 day on this avoids 4 days of tracking down a bug - and that 4 days is a lot less enjoyable. At QuickStreet I had a team of 5 developers, 2 testers, a program manager and a product manager (plus me). In 4 months (and half of these people started after the company was founded) we went for a one paragraph idea through specification, architecture, design, coding, unit testing, system testing, and depolyment. We delivered 120,000 lines of code for a J2EE (EJB 2.0) based server with no serious bugs, all specified functionality, and delivered in 1-1/2 hours before the promised delivery date. And when I wrote my firewall (www.defendtek.com), I did the same thing even though I was the only developer. (There were shortcuts in this case - I needed to comment for me, but not for others for example). This took about 3 months of nights and weekends and was 22,000 lines of code - for the program (3 programs actually). The testing code was probably another 20,000 lines or so of code. The barbarian cultures died out with their members asking why, why??? I know a number of programmers will reply back to this explaining why they are so good that they should be left alone to just write code. With lots of examples of why. But the bottom line is, it doesn't matter what you say, companies are finding gigantic improvements with a structured approach to coding. And the barbarian coders will die off. - dave ps - this is not to say all systems for structured coding are good. I have seen bad ones too. All I am saying is that there are numerous practices that have been repeatedly proven to provide significant increases in productivity.

    Dude (3.33 / 3) (#32)
    by wiredog on Sun Mar 10, 2002 at 08:01:35 PM EST

    You don't have to hit 'return' at the end of the line. Scoop word-wraps. Your post was painful to read.

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    [ Parent ]
    should post in text mode (3.00 / 2) (#34)
    by Delirium on Sun Mar 10, 2002 at 08:17:29 PM EST

    If you post in Text Mode I believe scoop will properly interpret line breaks.

    [ Parent ]
    Speaking of developing. (4.00 / 1) (#44)
    by bakuretsu on Mon Mar 11, 2002 at 12:50:34 AM EST

    Perhaps someone can change whatever specs they need to, or alter whichever bricks are required so that text mode is defaulted, or chosen in a user's preferences ;-D

    -- Airborne
        aka Bakuretsu
        The Bailiwick -- DESIGNHUB 2004
    [ Parent ]
    yes (4.00 / 1) (#51)
    by Delirium on Mon Mar 11, 2002 at 03:24:32 AM EST

    Text mode should be the default, I agree. A default of requiring HTML markup just to do something simple like type a comment makes k5 too much of a "for computer people only" site.

    [ Parent ]
    Why not both? (4.00 / 1) (#52)
    by Kalani on Mon Mar 11, 2002 at 03:28:31 AM EST

    A hybrid mode would still translate two line breaks into "<br><br>" and you'd also be able to put in whatever markup you want.

    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    That's what Slash has by default (4.00 / 1) (#54)
    by Delirium on Mon Mar 11, 2002 at 03:57:52 AM EST

    And K5 used to use Slash, but didn't copy this feature when Scoop was implemented. Not sure why, but it's useful, and the default for nearly every other webboard software.

    [ Parent ]
    Here (5.00 / 4) (#38)
    by Kalani on Sun Mar 10, 2002 at 08:37:53 PM EST

    Dave didn't have a ton of time and he's never posted here before. I asked him if he'd comment on this response to his article so he registered just for the comment. I don't think that he should be faulted for such a trivial mistake. The points that he brought up were more important. That having been said, here's his post reproduced with line breaks (maybe I'll finally get some sleep now):

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

    Hi;

    As the person who wrote the original article, I was asked to make a comment here. So here goes.

    First, I think Commando Coder is a bad term. What would be better is Barbarian Coder. I use the term barbarian not in the maurading hordes, but in the cultures that came before the anvent of farming and technology.

    The Barbarian Coder is self taught and attacks problems straight on with no thought for the future. In history the barbarian many times did defeat the civilized opponent. But over time civilization totally crushed the barbarian.

    I personally bounce back and forth between managing (recently V.P. at a start-up) and coding (wrote a firewall at home over the last 2 months). So I have had the opportunity to see this from both sides over the last 20 years. And both sides throughout my carear, not just in management recently.

    And what I have found is that any development project will be completed by any developer quicker and with a better end result, if some basic practices are applied to it. This includes a 1 person one week job to a 2 year 50 programmer job.

    Now the smaller jobs can be accomplished with the barbarian approach. But that doesn't mean they can be accomplished better. And many times it's much worse. Let me give some examples:

    1) The hero programmer. This individual, who generally is very smart and talented, can outproduce the other programmers. But he fights having a systematic approach to development because he can do it his way so fast. What happens is the company can never scale. As more developers come on, they can't write code that work's with the hero's code, because no one is sure what the other parts are doing. And the hero is god, so no one is going to "slow him down." And the company is limited by what the one hero can accomplish.

    2) The cluster fuck. Take a group of talented programmers and throw them at a problem without architecting and designing it first. And they will each diligently implement their piece of it - to find that the pieces don't workj together, that parts are missing, that parts are duplicated. And it is a horrendous effort to get these parts working together.

    3) Code it now, test it later. Without proper testing - FROM THE START - the code stays buggy. One bug is fixed and another pops up. Twenty testers are hired and they find so many bugs management gets even more upset. I don't care how good a developer is, without testing what ships will be crap.

    4) It's just a little thing. Occasionally you do have a small project that nothing else will get added to. But it's rare. What's much more common is it's a little 2 day project. Then a 1 day project to add something, then another day a month later. The online store I did for my company was written this way. And now it's a mess. It takes me 4 times as long to fix and test something than it should. But the cost of rewriting it is prohibitive so I live with the mess. If I'd followed my own rules... but it was just a little 2 day project that I would never add to - yeah right.

    5) Recoding is part of the business. Yes at times it is. But it's also a total waste of time when it's avoidable and that fact that sometimes it can't be avoided is no excuse for the times it can. I sometimes get mad at my kids when they screw up - but that's no excuse to get mad at them when something was not their fault.

    Here's my take on it. A lot of programmers are lazy and spoiled. They want to keep doing things the way they have been doing them. Learning to architect and design and unit test and properly comment is hard. So it's easier to say that one doesn't need to do that.

    But a professional programmer does understand that it's a necessary part of the job. That the small jobs are completed faster and better and the big jobs are completed this way. It doesn't mean it's enjoyable. But when I'm writing unit tests I just keep telling myself, 1 day on this avoids 4 days of tracking down a bug - and that 4 days is a lot less enjoyable.

    At QuickStreet I had a team of 5 developers, 2 testers, a program manager and a product manager (plus me). In 4 months (and half of these people started after the company was founded) we went for a one paragraph idea through specification, architecture, design, coding, unit testing, system testing, and depolyment. We delivered 120,000 lines of code for a J2EE (EJB 2.0) based server with no serious bugs, all specified functionality, and delivered in 1-1/2 hours before the promised delivery date.

    And when I wrote my firewall (www.defendtek.com), I did the same thing even though I was the only developer. (There were shortcuts in this case - I needed to comment for me, but not for others for example). This took about 3 months of nights and weekends and was 22,000 lines of code - for the program (3 programs actually). The testing code was probably another 20,000 lines or so of code.

    The barbarian cultures died out with their members asking why, why???

    I know a number of programmers will reply back to this explaining why they are so good that they should be left alone to just write code. With lots of examples of why. But the bottom line is, it doesn't matter what you say, companies are finding gigantic improvements with a structured approach to coding. And the barbarian coders will die off.

    - dave

    ps - this is not to say all systems for structured coding are good. I have seen bad ones too. All I am saying is that there are numerous practices that have been repeatedly proven to provide significant increases in productivity.

    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    Thanks (2.00 / 1) (#41)
    by wiredog on Sun Mar 10, 2002 at 10:24:14 PM EST

    Much better.

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    [ Parent ]
    Barbarian == Commando (4.66 / 6) (#42)
    by localroger on Sun Mar 10, 2002 at 10:35:03 PM EST

    Thank you for taking the time to reply to this, David. I appreciate that yours is a busy schedule and this was a bit unexpected.

    I don't think you can draw much of a distinction between "barbarian" and "civilized" warfare. The main reason civilization wiped out the barbarians was better technology, a metasolution which does not apply to the analogy with software development. As the "civlized" programmers love to keep reminding us, there is no "magic bullet" -- the programming equivalent of "atomic bomb."

    Rome did not wipe out the barbarians; it worked the other way around. In America, it was the colonists who invented such "barbarian" tactics as guerrilla warfare who defeated the "civilized" British with their generally superior funding and weaponry.

    The Barbarian Coder is self taught and attacks problems straight on with no thought for the future.

    I think I covered that in the section on the "second epiphany." The commando/barbarian/whatever who refuses to document his code or to adjust to the requirements of others is a dangerous loose cannon. I think there is a middle ground between the anal-retentive spec-bound coder and the prima donna who has to have it his own way; you can use loose specifications on a small project yet work within a team by being willing to adapt to the needs of others.

    I will start out a 10KLOC project with a very, very loose specification; maybe 2 or 3 pages in a word processor, and I will start building the low-level functions I expect to be helpful implementing it. As my bricks grow I sharpen the spec toward what they indicate will be both possible and reliable. If something looks awkward, I change it at one end or the other. Sometimes it means writing new bricks; sometimes it means changing the spec. Either way it occurs pretty fast.

    I strongly disagree (for reasons which should be obvious from my article) that the small project is dying away. A large number of my projects have been end-user interfaces for these large systems; I get the jobs I get because my approach works better at that scale, and in that situation. SAP has components to do a lot of the things I do; I wouldn't be getting the jobs I get if those components worked as advertised.

    Learning to architect and design and unit test and properly comment is hard.

    I don't see what's so hard about it, since I do all these things. I just do the "architect" part in my head. I'm a strong believer in testing, though I don't use a formal procedure; it's actually kind of fun writing test code, because it proves out your work. (Then again, I always enjoyed test days when I was in school, so maybe it's just me.) I learned the value of comments the hard way. Since I hate failure, it didn't take long to get the lesson.

    "Informal" doesn't mean "entirely unplanned." What appears to be a disagreement in our case is really about choices of words, and formality or informality of procedures which exist in both our cases. You've learned the value of formalizing certain things; I'd be the last to say that that this is an entirely bad thing. Both formality and informality can be overdone. I lean toward the informal, and it's an approach which works for me day in and day out. It is just as wrong to discount informality as it is for the "code barbarian" to refuse to comment his code because "anyone worthy will understand it."

    I can haz blog!
    [ Parent ]

    Maybe we're agreeing (none / 0) (#72)
    by DavidThielen on Mon Mar 11, 2002 at 03:02:53 PM EST

    Hi;

    I don't think I ever said that certain steps need to be formalized, just that they need to occur. On smaller projects architecture can be 1/2 hour of thinking and then e-mailing a couple of paragraphs to others to get their feedback. (I do think the feedback step is very valuable.)

    As to small projects, my point wasn't that there are no small projects. But that an awful lot of small projects are actually sizable projects that are done in small pieces, with no thought that another small piece will follow.

    - dave

    [ Parent ]
    you tragically misinterpret history (2.50 / 2) (#47)
    by turmeric on Mon Mar 11, 2002 at 01:20:03 AM EST

    barbarian societies were often hunter and gatherer or agricultural, and hence were very aware of the effect their actions had upon the environment, which is in effect 'thinking about the future'.

    so called civilized countries generally act on the 'greedy algorithm', ignoring what will happen 50 years from now, or even 10 years from now, taking all sorts of risks.

    [ Parent ]

    Equivocation (5.00 / 1) (#50)
    by Kalani on Mon Mar 11, 2002 at 02:27:11 AM EST

    He meant "barbarians" in the sense of strongly anti-social creatures. Obviously the agricultural societies did not fit this criteria (and it could be argued that such agricultural societies formed the bedrock upon which modern civilization is built ... so such people are rather far from "barbarous").

    Anyway, I think you are probably taking the analogy a bit too far. The point is that organized societies spread while small tribal or individual humans died off or fell into a niche. I think that's probably about as far as the analogy was supposed to go.

    Thank you for your comment.

    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    I don't think so (4.00 / 1) (#71)
    by DavidThielen on Mon Mar 11, 2002 at 03:00:05 PM EST

    Barbarian societies were generally hunter/gather and a large part of the reason many would have to move is that they would hunt out an area and have to move on.

    There are no large indigenous animals in North America, South America (except the llama) or Australia.

    Why?

    Because by the time the human race migrated to those continents they had become such profecient hunters, they killed off all large animals before the animals could learn to evade humans.

    Barbarian societies did not have the ability to affect the environment on the scale modern man does. But what affect they could have, they generally did with little to no thought to it's effect.


    [ Parent ]
    Barbarians vs Civilized Society (none / 0) (#79)
    by raelin on Mon Mar 11, 2002 at 10:34:21 PM EST

    I have to totally disagree with you on the large indigenous animals point. Buffalo were plentiful until after the trains arrived. The Indians weren't the ones who thinned the herds out, it was us. Mostly as a method of driving the Indians away, true; but it still holds up what he was saying.
    I have no such data for the Maori, though I suspect it was similar in nature. Basically, Barbarians couldn't fend for themselves without these herds of animals, so they took what they needed and used everything they took.

    This whole analogy has been taken too far, though.
    --Wes

    [ Parent ]
    Completely OT, but... (5.00 / 1) (#80)
    by spcmanspiff on Mon Mar 11, 2002 at 10:42:02 PM EST

    According to my favorite source for these sorts of things lately [1], many of the large mammal extinctions in N. America (mammoth, e.g.) were coincident with the theorized arrival of humans ...

    There are many well-documented examples, on a smaller scale, of large flightless bird extinctions soon after humans arrived.

    I personally feel that all the romanticizing about harmony with nature in primitive societies is on shaky factual ground at best. :)

    [1] Guns, Germs & Steel



    [ Parent ]

    Guns, Germs & Steel (none / 0) (#82)
    by DavidThielen on Mon Mar 11, 2002 at 11:22:32 PM EST

    Excellent excellent book!

    [ Parent ]
    Barbarian != Commando (4.83 / 6) (#53)
    by enkidu on Mon Mar 11, 2002 at 03:46:06 AM EST

    As a somewhat experienced programmer currently working in a commando team (3 man team, one man to deal with managment, and two to design, code and coordinate.) I'd like to point out where your assumptions go wrong. I have experience with some of your examples

    • the Hero Programmer-this cost 12 programmers 6 months on one project.
    • the cluster fuck-the Hero Programmer was let loose because we didn't have a plan when we started our attack.
    • Code it now, test it later-if you can't test it, then you havn't written it.
    • It's just a little thing-Even little things should be done right.
    • Recoding is part of the business-Why yes, it is :-).

    Here are the differences I see between barbarians and commandos.

    • Commandos aren't heros-Any real expert on commandos will tell you that commandos aren't cowboys and aren't heros. Commandos don't take risks they don't need to take. They'll do risky operations but only after they've given themselves as many advantages as possible. Seals prefer to work at night because they know that they have the advantage at night.
    • Commandos know their tools and the terrain. The most common problem I see in the grunts I work with is not reading their manuals and not obeying the 7th of the 10 Commandments for C Programmers. By contrast, commandos know how to disassemble their weapons, fix them, and shoot them, that is, they know their compiers and their error messages, they know their libraries and their functions and keep up with new developments.
    • Barbarians attack. Commandos recon, plan, organize and attack. Good commandos avoid the dangers of "the cluster fuck" and "code it now and test it later" by planning and coordinating with associated teams, organizing call signals, designing the assault and attacking efficiently.
    • Barbarians follow their leader. Commandos are given objectives, express opinions, and help plan attacks.
    • Barbarians grunt. Commandos communicate. When commandos get into trouble, they communicate at the first best opportunity. They don't communicate throught channels ("have your manager talk to their manager talk to their guys"), but deliver the information to those who need to know ASAP. They work with the groups they trust to find a solution and implement it quickly. Grunts hang around and wait for orders from above.
    • Recoding is a good thing because situations and requirements change. Recoding allows you to design it better, avoid the problems you encountered, keep the good hard steel blocks that you made and throw out the brittle bricks that you don't want.

    There's a need for grunts and a need for commandos. But for projects that you want done quickly and well, you want teams of commandos organized by function with lots of internal communication and little outside interference.

    enkidu "Commando in training"

    [ Parent ]

    Going overboard on the commando thing (none / 0) (#70)
    by DavidThielen on Mon Mar 11, 2002 at 02:55:49 PM EST

    Hi;

    It seems people are going overboard using the term Coding Commando and then insisting that anything having to do with military special forces totally applies.

    Ok, to use that application, military special forces train and practice and rehearse a ton. So if anything, a commando would do more architecture, documentation, testing, etc. than a regular programmer.

    And the bottom line - a military comando never wants to have to do the equivilent of recoding - because that means people died the first time.

    The same holds for programming. Most (not all) recoding is avoidable by thinking the work through.

    - dave

    [ Parent ]
    Going overboard (none / 0) (#74)
    by enkidu on Mon Mar 11, 2002 at 03:27:57 PM EST

    Ok, to use that application, military special forces train and practice and rehearse a ton. So if anything, a commando would do more architecture, documentation, testing, etc. than a regular programmer.
    When working in teams, commando coders would do lots of documentation, brainstorming and testing but in an efficient manner. No lengthy meeting about meeting about schedules. Just do it. But yes, documentation is crucial to doing a good job.
    And the bottom line - a military comando never wants to have to do the equivilent of recoding - because that means people died the first time.

    The same holds for programming. Most (not all) recoding is avoidable by thinking the work through.

    I didn't take the combat analogy into recoding precisely for those reasons. Metaphors can only stretch so far. I disagree about your conclusion though. Until a tool is used in a production environment, it's impossible to predict the many different ways people will (ab)use it. If you try and thinking the work through too much in the beginning, you end up building too much stuff into it to start with, (there is such a thing as too much flexibility) taking up development time and testing. IMHO, it's better to start out small and build up from there, rewriting when you need to and when you have a better idea of what the requirements are.

    [ Parent ]
    22,000 lines of code? (none / 0) (#99)
    by QuantumG on Thu Mar 14, 2002 at 05:00:21 AM EST

    First of all, it's not a "firewall". Maybe it's a "software firewall" but the effectiveness of such a device is about 100 times less than a "hardware firewall" (which is a largely inaccurate term). Secondly, 22 thousand lines of code?! For what? It's a packet filter! How the hell can you write 22 thousand lines of code for something so trivial and actually think that is a good thing. Plus it's a security product, so I assume you have checked and double checked every line of that code.

    Gun fire is the sound of freedom.
    [ Parent ]
    Possible scale impedance mismatch (4.66 / 9) (#28)
    by johnny on Sun Mar 10, 2002 at 07:26:13 PM EST

    It seems to me that two of the principals in this discussion are talking about principles of differenct orders of magnitude. localroger is talking about small, and Theilen is talking about big.

    I long time ago (about 1994) and for a short time, I was chair of the Software Development Architecture Team (SDAT) at Sun Microsystems. This cross-company team was charged with the care, feeding, and wide dissemination Sun's Software Development Framework ("SDF"), which was the overall process (process in the ISO9000 sense) by which Sun developed software. At that time there were probably about 600 full-time software engineers at Sun; the largest chunk were working on the OS, but there were compiler, networking, heck, even applications people. It was a big company with many divisions & local cultures, some of which derived from organizations that Sun had swallowed wholesale-- such as a small company in Moscow, and that company whose name I'm forgetting, from southern California that used to make a Unix for X86. (Interactive??)

    Our job at SDAT was to promote the notion of SDF as a common language for discussing projects and for making contracts -- contracts within software engineering itself, and between software and the other functional groups of the corporation.

    The SDF itself was largely the creation of Rob Gingell, one of the architects of Sun's Unix from the early early days, and Katy Dickensen (sp? Sorry Katy, I cannot remember which variant you use!), who used to proudly call herself a bureaucrat. I inherited stewardship of their process after the original team had done most of the heavy lifting.

    SDF was a revolutionary development at Sun, and it never would have happened if it hadn't had a proponent of Rob's stature. All Sun code monkeys, especially the old-time Unix guys, thought of themselves as "commandos", and they were going to be goddamned if some suit (brass?) was going to cramp their style. Process? Fuck you. We don't need no stinking process!

    Then a major overhaul of the Operating System, originally planned as a nine month project, took nearly three years to complete. Not only did it slip three times its length, it did so in small increments, which only made the agony worse. After that fiasco, Rob was able to sell his ideas on improving process. The commandos were too busy wiping egg off their faces to put up any resistance.

    But here's the thing. The SDF has nothing to say about how one conducts a three-person project. That's up to managerial discretion. When you have 325 engineers overhauling an operating system that is in active use by several hundred thousand paying customers, three-person projects are in the noise. Literally. Architectural decisions at that scale are so unimportant that the SDF has virtually nothing to say about them.

    Rather what the process speaks to is, how do we decide what is a local decision and what is a global decision? How do we decide what to build, and how do we decide on what time-scale to build? How to we define hand-offs and architectural boundaries, how do we effect hand-offs and boundaries, and how do we adjudicate disputes?How do we communicate our plans to those who need to know what we're doing, and what is our feedback mechanism for self-correction, in the large, when we've made a mistake in calculating our original trajectories?

    All of these issues had to do with projects in the large, in the context of several hundred persons working on some aspects of a thing. In the small, in the particulars, it meant nothing to us whether individual project teams percieved themselves as jarheads/grunts or as commandos. That was strictly a matter to be decided by the local manager, who was reponsible for the code produced by his or her team.

    yr frn,
    jrs
    Get your free download of prizewinning novels Acts of the Apostles and Cheap Complex Devices.

    The SDF (5.00 / 2) (#33)
    by wiredog on Sun Mar 10, 2002 at 08:09:29 PM EST

    The SDF, and those projects, sound like good fodder for k5 articles. Or maybe even a book.

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    [ Parent ]
    Article and book (4.00 / 1) (#59)
    by johnny on Mon Mar 11, 2002 at 08:51:22 AM EST

    I might-could write a short article that outlines the SDF as I remember it. Of course it was a long time ago, and though I think it's interesting in the historical sense, it might be more interesting if we could get somebody to write about whatever the SDF has evolved into. (I left Sun's emlploy in 1994).

    Once upon a time I set out to write a book on software process improvement. In fact, I had a contract from O'Reilly & Associates to write it. However, I kinda freaked out and had a brain fart and wrote my novel instead. Somehow the idea of writing that book still gives me shivers. But maybe someday I'll hop back into the saddle on the horse that threw me on my head.

    yr frn,
    jrs
    Get your free download of prizewinning novels Acts of the Apostles and Cheap Complex Devices.
    [ Parent ]

    Writing the book (4.50 / 2) (#60)
    by wiredog on Mon Mar 11, 2002 at 09:09:09 AM EST

    From what I've heard, talking to professional writers at cons, you have to start small and get a rep. Short stories and novellas, then the Big Great American Novel.

    Clancy got lucky. "Hunt For Red October" was published by Naval Institute press, which mainly does extremely wonky stuff. One step above boutique publishing. The success of that book surprised the hell out of them.

    Peoples Front To Reunite Gondwanaland: "Stop the Laurasian Separatist Movement!"
    [ Parent ]

    Commando Coder Acadamy (3.00 / 4) (#31)
    by egerlach on Sun Mar 10, 2002 at 07:55:23 PM EST

    First of all, I'd like to comment that I *love* this analogy. I was a Sea Cadet for seven years, and I'm thinking of going into the Naval Reserve. I think the General/Major/Commando/Grunt distinction fits well into software development. I think I'm gonna stick with this one :)

    I find it interesting that earlier this morning I was reading this article on flipcode, which deals with the fact that most, if not all universities are now geared to pumping out Grunts, which is to say they pump out people who can code, but not necessarily people who have more than a specific set of skills or can adapt to new situations. If you haven't read it, it's good, you should read it. Maybe I should submit it... hmmm....

    Anywho, I was thinking as a result of that, especially in light of this k5 article, should there be a Commando CS Acadamy? A place where Grunts or Recruits can go to receive Commando training? A place where the emphasis is to driving people towards the epiphanies, and to making them skilled in and fully able to understand every aspect of the computer and its operation. Like real Commando Boot Camp, if you can't keep up you leave. It's hard, it's grueling, but when you come out at the end you're 5 to 25 times better than when you went in. You're the best of the best. Anyone have any thoughts on it?

    "Free beer tends to lead to free speech"
    I also read flipcode ... (3.50 / 2) (#36)
    by Kalani on Sun Mar 10, 2002 at 08:21:30 PM EST

    ... as you will probably see in my sig. Although the author (Kaap) lamented on the decline in hard-core CS theory, you'll see that some people spoke out on the other side. Specifically, there were a number of people who made the point that there are plenty of graduate programs in CS that also will take him as far into the theory as he chooses to go. Most flipcoders have a very deep CS education, even if they don't get it from undergraduate classes (as was also pointed out by a few posters on there).

    In any case, there are already schools that exist to crank out "grunts." They're called "ITT Tech" and "DeVry."

    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    sorry, replace "Kaap" with "Jaap&qu (none / 0) (#37)
    by Kalani on Sun Mar 10, 2002 at 08:30:10 PM EST



    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    Amazing article (4.00 / 2) (#39)
    by tzanger on Sun Mar 10, 2002 at 09:00:39 PM EST

    It's been nagging at me for years where I fit in. Now it's clear: I too am a code commando. While I can do things that amaze and impress and defy doability, I am also bogged down in large projects and have trouble finishing all aspects of a single project on my own.

    This article is actually quite timely since I am seriously considering starting my own design house (electronic design) and I've been wondering if I really had what it took. Now I know what exactly it is that has been nagging at me and what I need to do in order to succeed at this: ground support. I either need to learn how to both "blow up a bridge" and "organize the D-Day Normandy invasion." I need to learn how to do it all or find someone (some people) who can do the things I can't and keep the details in order while letting me continue to amaze the crowd with things that "just can't be done."

    Thank you, localroger; it would have taken me quite some time to pin this down quite this accurately on my own. I'm printing this article out. Thank you again.



    Books on why large projects are different (5.00 / 3) (#55)
    by obsidian head on Mon Mar 11, 2002 at 04:53:26 AM EST

    In addition to Mythical Man-Month, another fine book is Code Complete. Both talk heavily about the main problem for commando coders, which is system integration. The first book defines the problem, and the second sketches out different ways that it's dealt with.

    I've often written nice pieces of code that pass all careful unit tests, but then takes me seemingly forever to integrate into the wider system. But that is the nature of integration work. It makes you something like 10X slower. You are often interacting with bad APIs and bugs that you must explain to other teams.

    Integration work is nontrivial. I am now looking at systems like Sourceforge, and yes even Scoop, to facilitate more efficient human communication. It can be done, but it should be understood in its own right. (Fortunately this is a decades-old problem, and some people have gotten pretty good at it.)

    [ Parent ]

    Commando isn't appropriate (3.00 / 3) (#45)
    by scheme on Mon Mar 11, 2002 at 12:52:19 AM EST

    The use of the term commando isn't really appropriate in this context. The few people I know who were former members of a special miltitary unit have emphasized that teamwork and working together was a very important part of their training. Yes, they were highly trained but their biggest advantage came from the fact that they were able to work really well as an unit.


    "Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. THAT'S relativity." --Albert Einstein


    Units (4.00 / 1) (#64)
    by ucblockhead on Mon Mar 11, 2002 at 01:00:31 PM EST

    Commandos are trained to operate in small units, independent of control, which is the analogy I think localroger is trying to make.
    -----------------------
    This is k5. We're all tools - duxup
    [ Parent ]
    "Commando?" (2.66 / 3) (#57)
    by RobotSlave on Mon Mar 11, 2002 at 05:51:00 AM EST

    And they wonder why there aren't more women in IT.

    What is a female commando? (3.50 / 4) (#58)
    by maroberts on Mon Mar 11, 2002 at 06:23:48 AM EST

    ..a commandoe, maybe ?

    Actually, the more women who go commando the better IMO.
    ~~~
    The greatest trick the Devil pulled was to convince the world he didn't exist -- Verbil Kint, The Usual Suspects
    [ Parent ]
    Military analogies (4.00 / 1) (#62)
    by Salamander on Mon Mar 11, 2002 at 12:49:31 PM EST

    I'd heard a very similar analogy between software and military specialties a while ago, but it had three categories, not two: commandos (originators), infantry (main-line programmers) and MPs (maintainers). Even before that, I'd taken to describing myself as a "software paratrooper", which I think is more appropriate than "commando" because it emphasizes rapid mobility rather than covert operations and sabotage. "Recon" might be appropriate too.

    I think the military analogies are very interesting to explore, though of course one must always remember the limits of analogies. I've met people whose roles within an organization could immediately be characterized as, say, quartermasters (tool-makers) or medical corpsmen (expert debuggers), and I've actually used the military term REMF to refer to those inevitable clueless meddlers from HQ. The military is actually a good example of an organization designed to operate in unknown and/or hostile environments, which is a good description of writing software for an OS designed by fools. It probably shouldn't be too surprising to see many parallels.



    Sledgehammers stories are good (4.80 / 5) (#69)
    by selkirk on Mon Mar 11, 2002 at 02:37:25 PM EST

    Excellent article. I really like the sledge hammer story. Every programmer should have something like this happen to them. I get really frustrated sometimes watching the "grunts" come out of college with no concept of the potential consequences of their actions.

    My "Epiphany Incident" involved a room of 25 order takers telling callers "I can't take your order right now because the computer is down."

    The worst one of these I saw was an inventory tracking program that became an inventory randomizing program. Unfortunately, this was discovered about two dozen semi-truck loads too late. After it was discovered we had to have a pair of programmers sit on the loading dock repairing database corruption 24 hours a day until the software could be fixed. (The program was such a mess that it took a few days to fix and months to track down all the bad data.)

    The coolest one I encountered was an error in a box ordering program which resulted in a box being delivered which was big enough for an entire production crew to stand in and have a picture taken. The bug was reported to the programmer in the form of this picture.

    Anyone else have any good personal stories of the consequences of bugs?

    What a load of crap! (3.75 / 4) (#75)
    by wurp on Mon Mar 11, 2002 at 04:34:58 PM EST

    This reminds me very much of the programmer's stone: it's an attempt to elevate yourself while putting down others. It is also a load of crap.

    Firstly, being difficult to work with is NOT A VIRTUE. You can find jobs in which it's not too much of a detriment, but it will always be a strike against you.

    Failure to comment code that is obvious to you at the moment but might be considered obscure by others (or by yourself in another mindset) is NOT A VIRTUE. We all (or at least most) have moments of genius, some more frequently and longer than others, and we all have moments of idiocy. Occasionally, we mix the two up. Comments can make the difference between figuring out after the fact which of the two you were, and that's ignoring the obvious benefits given when someone else can actually read your code later on.

    Certainly there are better coders than others. Certainly there are things we can do to become better coders and engineers. Some of the things you list fall into that category. However, attaching some ridiculously romantic label to yourself and putting both your flaws and your strengths under that label just glorifies bad behavior. Figure out what you do wrong and what you do right, and focus on that. The label is bullshit.

    ---
    Buy my stuff
    Throwing crap is NOT A VIRTUE (1.00 / 1) (#81)
    by Some call me Tim on Mon Mar 11, 2002 at 11:02:20 PM EST

    localroger said nothing to the effect that being difficult to work with was a virtue. Nor did he say anything about not commenting code being a virtue--in fact, he said the opposite.

    All too often people who are NOT genius programmers throw stones (or crap) at those of us who are. :) The article resonated with me. I've been there, with the insuffcient hardware and the impossible demands. I regularly accomplish tasks that I'm told are impossible. For fun. Before breakfast. :)

    If you don't have that attitude, then don't try to be a commando programmer. The process would kick the crap out of you.

    Tim

    P.S. I do comment my code. I even use Doxygen/Javadoc documentation. And I use revision control and other modern processes. They slow me down, but in the long run I get better results.



    [ Parent ]
    difficult to work with is NOT A VIRTUE (none / 0) (#83)
    by DavidThielen on Mon Mar 11, 2002 at 11:27:20 PM EST

    >>> Firstly, being difficult to work with is NOT A VIRTUE. You can find jobs in which it's not too much of a detriment, but it will always be a strike against you.

    Exactly. A team that works well together is much more productive than the sum of their parts. So I always look for how well someone will work with others before hiring. Because one problem child drags everyone down. Do that to a good team and the total productivity including the new person is less than it was without them.


    >>> However, attaching some ridiculously romantic label to yourself and putting both your flaws and your strengths under that label just glorifies bad behavior.

    Very well put. When managing or when interviewing potential peers (when I'm developing), I don't want someone who won't learn how to improve. When the rest of us improve, that person is then slowing us down.

    thanks - dave

    [ Parent ]
    University CS courses (4.50 / 4) (#76)
    by Fon2d2 on Mon Mar 11, 2002 at 05:34:37 PM EST

    I don't know when but I stopped believing in the university as a good way to teach computer science a long time ago. I agree that the only way to really come to appreciate the rudimentary principles of architecture, design, commenting and testing is with lots of personal experience. Unfortunately, a university education will never provide enough practical experience. And concepts will never be explained quite well enough. Or maybe I'm just pessimistic. But when there's something I want or need to learn, I don't just go and take it for granted I ought to sign up for a class. I usually go and find a book on the topic.

    Quick question (4.00 / 1) (#77)
    by Ken Pompadour on Mon Mar 11, 2002 at 05:44:17 PM EST

    How many Computer Science courses have you personally taken? Is it non-zero?

    Just for the record, I agree... Computer Science should be dismantled and it's remains spread to the Software Engineering major and the general Mathematics major.


    ...The target is countrymen, friends and family... they have to die too. - candid trhurler
    [ Parent ]
    I've taken more than zero ... (5.00 / 1) (#92)
    by Mr.Surly on Tue Mar 12, 2002 at 01:53:02 PM EST

    I've taken quite a few University CS classes (C/C++, Pascal, COBOL (shudder), etc), plus I've done Assembly, Perl (my primary development lnaguage now, along with C++). Here's my conclusion:

    Most University CS Instructors are idiots. They wouldn't last 10 minutes in a "real" programming job. I know several other programmers, all in different companies, all of whom had exactly the same experience: University courses taught a lot of theory and made sure you knew what features existed in the language (mostly), but were pretty much useless for a real-world programming task.

    As far as mathematics goes: If you understand basic Algebra (5 + x = 17. Solve for x), chances are you already know way more math than you'll need for most programming tasks.

    [ Parent ]
    Don't agree, but ... (none / 0) (#97)
    by Kalani on Wed Mar 13, 2002 at 02:38:06 AM EST

    As far as mathematics goes: If you understand basic Algebra (5 + x = 17. Solve for x), chances are you already know way more math than you'll need for most programming tasks.

    What sort of programs do you usually write?

    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    I'll tell you (none / 0) (#102)
    by Mr.Surly on Thu Mar 28, 2002 at 06:19:56 PM EST

    Usually database-driven web sites and such. However, recently I've done stuff such as:

    Creating a report generation system that reads report definitions that are XML, and generates a PostScript report (think Crystal Reports without the GUI)

    An 'expression parser' that lets you say (a = 5 * 3 +q). This started in Perl, but I've moved to C++ and Bison.

    In the past, I taught myself how to do wireframe 3D graphics. This involved a little bit of trig, but (surprisingly) the actual wireframe rendering is a simple algebraic expression.

    [ Parent ]
    Ah, I see ... (none / 0) (#103)
    by Kalani on Fri Mar 29, 2002 at 01:44:46 AM EST

    I've done things like what you mention, but (since you bring up wireframe graphics) the projection equations for axis-aligned perspective projections are derived using parametric equations. That's not anything terribly difficult, but it's more involved than basic high school algebra. Also, if you ever got into more sophisticated 3D graphics, you'd likely generate wireframe approximations to continuous curved surfaces (and that would involve some advanced calculus). That's not to mention the simulation of motion and physical systems, which would require Calc also.

    Since you mention parsing, that brings up Deterministic Finite Automata. Then there's always the handy discrete structures stuff (which often affects your programs, even if only indirectly).

    There are a lot of concepts in CS that are taken from various branches of higher mathematics (formal logic, to demonstrate another obvious one).

    -----
    "I [think] that ultimately physics will not require a mathematical statement; in the end the machinery will be revealed and the laws will turn out to be simple, like the checker board."
    --Richard Feynman
    [ Parent ]
    Wireframe graphics (none / 0) (#104)
    by Mr.Surly on Thu May 09, 2002 at 05:10:46 PM EST

    I'm not going to pretend I know what a 'axis-aligned perspective', though a quick Google search shows quite a few hits. Like I said, I was self-taught, and I don't mean I checked out a book. I literally did all of it in my head. It was very simple, and it used basic algebra.

    The closest I ever got to dealing with curved surfaces would be using bezier patches ...

    Your mention of DFA make me think of Hofstader, and a quote that always makes me laugh:

    "A logician trying to explain to a programmer what it is to be logical is kind of like an ichthyologist trying to explain to a fish what it is to be wet."

    [ Parent ]
    I was hoping you'd respond :) (5.00 / 1) (#105)
    by Kalani on Fri May 10, 2002 at 12:18:10 AM EST

    I'm not going to pretend I know what a 'axis-aligned perspective'

    It just means that you perform the projection assuming that the "camera" (or projection point(s) and projection surface(s)) is aligned with one of the axes. That's how, with the standard four/five-sided pyramid view volume, you can reduce the problem of 3D projection to that of two 2D projections.

    Like I said, I was self-taught, and I don't mean I checked out a book. I literally did all of it in my head. It was very simple, and it used basic algebra.

    Anyway, my point was just that other techniques in mathematics are useful (or they can be useful). I like mathematics for its own sake, but there are obviously plenty of other applications of advanced math in various fields.

    The closest I ever got to dealing with curved surfaces would be using bezier patches

    As far as general computer graphics goes, that's pretty much all you need to know about curved surfaces (there are b-spline surfaces also, usually non-uniform rational ones are used, but they're just a generalization of the bezier spline/surface). Still, I am wondering how you understand Bezier splines without Calc? As I learned about the Bezier Spline, I arrived at the problem of deducing its form from the Hermite Spline (which requires you to use differentiation to come up with the generating equations).

    Your mention of DFA make me think of Hofstader, and a quote that always makes me laugh

    Is that Hofstader of "Computer Graphics: Principles and Practice" fame?

    "A logician trying to explain to a programmer what it is to be logical is kind of like an ichthyologist trying to explain to a fish what it is to be wet."

    I agree with that, but the point of learning formal logic (or any other higher math) is not to actually LEARN the new thing (at least not usually), because in most cases you already understand what it is that the math covers. Rather the purpose is to formalize your understanding of it, so that you can discover new things by virtue of the formal system itself, or so that you can communicate with others (or more simply document your work, etc etc).

    -----
    "Nothing says 'final boss' like a giant brain in a tube."
    -- Udderdude on flipcode.com
    [ Parent ]
    Computer science is not programming (none / 0) (#106)
    by lakeland on Thu Oct 03, 2002 at 12:01:11 AM EST

    I have to take issue with your comment that uni can't teach CS well.

    Computer science is not programming, it has very little to do with programming. Sure programs are the tools of the trade, and I'd generally expect a computer scientist to be a skilled enough programmer.  Similarly it is essential for every discipline to impart a basic understanding of the tools to the disciples^Wstudents, and so I expect most graduates to have some programming skills.

    But try reading a CS syllabus sometime; programming won't even be mentioned for most courses. As a student you'll have to spend many long hours in the lab implementing the ideas but the thing you're marked on is your report on what happened when you ran your program(s). Because the instructors need students to test ideas, they have to impart the practical skills necessary. Hence most CS depts have a intro to computing (COMP101) paper,  and at higher levels you might see Intro to Java, Advanced C++, etc. Those papers have nothing to do with CS, they're just giving you the skills to complete the other papers.

    Another way of seeing this: a naturally brilliant programmer with 20 years experience would fail an 'introduction to computer science' exam because they never seriously thought about the theory, and the highest scoring CS graduate may struggle to write a program with more than 100 LOC.

    Now, you might say the job of a CS dept. is to churn out code monkeys and if its grads can't cut code then they're hopeless. Partially you've got a point, though you would be better employing a programming graduate. The stuff I do day-to-day could_not_be_done by you or the aforementioned programming expert, it requires developing research ideas from journals on probability theory and journals on linguistics, combining them and testing the results. Classic computer science really -- work out an idea, implement it, test the implementation, write up some results.

    The programs I write are moderatly complicated -- The double ended bounded skiplist or the heuristic search encapsulated in five loops might cause you a bit of grief -- But they're not really that complicated and it is quite possible you could have implemented them faster and better than I did.  The program is irrelevant to what I'm doing, when I write about my results I won't even mention the program. If you can't work out the theory to test you've failed before you've written a single line of code.

    As for the relative merits of a class or a book or whatever, well, to each his own. I don't care what you learn best from, but judging a CS course by how well it teaches your programming is like judging a MD course by how well it teaches you bandaging.

    [ Parent ]

    A little diffrent (4.85 / 7) (#78)
    by bored on Mon Mar 11, 2002 at 07:55:46 PM EST

    First a short background, I've thought about this a lot and I'm glad someone else finally brought it up. I've worked on everything from small personal hardware tweak utilities to large scale projects at major companies where my changes were .01% of the total project done by hundreds. During this time i've seen everything from turf wars where everyone maintains their own code base and tries to bind it together at the end, to process so rigorous that it takes 10x as long to deal with the process than to actually find and make the changes.

    During this time I've swung all over the spectrum looking for a real solution. I've also come to a number of conclusions. These conclusions are slowly forming a huge paper i've been writing, in summary here are just a few ideas.

    • There is a good chance that the 'great' coder isn't all that great. I've found the fact that situations define the person is a bigger part of the picture. Everyone has their strong points and sometimes the local code guru is just someone who has a better understanding of the particular situation or is the person in the lime light. This seems completely false until you put them in them in a different situation. Take them an throw them into a large existing project and tell them to make some significant change for fix some obscure bug. Repeat this a few times with different projects, the truly good ones will always excel.
    • Trying to define development, especially early project development as top down or bottom up is futile and only causes problems when developing a new product. In reality the really good products seem to have had an iterative development process. Any sufficiently complex project CANNOT be completely top down or bottom up simply because there are two many circular dependencies. Removing as many of these circular dependencies as possible and tightly defining interfaces is good but doesn't really solve the problem.
    • Design is good but it too needs feedback loops unless the problem is well understood. I've come to understand this as the problem between HW projects and SW projects. HW projects often times are just new versions of the same thing and they have well defined interfaces. CPU's have well defined instruction sets and the expected types of IO behavior are well understood. When designing a new processor most of the time there are people on the team who have done it before and break everything up in similar manners to the way it was done before. SW projects though often times aren't just new better versions of the old product. Instead of starting over for each successive version of M$ word they just import the old crap and hack on some new features. When starting a new word processor like word most of the people working on it probably have never done a word processor in their lives. Because of this it doesn't matter how good the programmers/designers are they will miss stuff. The programmers will just make a hackage mess with dependencies everywhere because that will be the easiest way to do something until it reaches a point where its unmaintainable and unstable. The designers will design away missing critical issues because they don't have any real feedback. This is why every new SW project should have a prototype This is a PROTOTYPE all of the code should be thrown away, every last piece! The designers and the coders then need to sit down and do a real design. The prototype can be used for bootstrapping the real product but every last line of the original should be thrown away (or at least touched by someone doing a code audit). The managers can go to hell if they don't want a prototype. Just like they can accept that designing the product will save them time and money in the long run they have to understand that if they have a green team working on something they have never done before then there had better be a prototype.
    • Use modern tools and code methods, fire the unix guy who uses pointers everywhere in his C code (and the people carrying around copies of K&R). Things like exceptions were invented to solve the problem of coders who can't check return values. No matter how good they think they are, programmers suck, they forget shit, and if it doesn't fail during testing then it probably won't get an error check. Then in the field it will cost big $ to solve that 1 line omission. Most of the modern language features were invented to solve real problems, someone didn't just decide one day to complicate C for the hell of it and add a bunch of esoteric features. They concluded that the same problems were being made and solved over and over and decided that the compiler could solve them better. It took me 10 years but I finally noticed something, sometimes those slow careful coders with the 'juvenile' coding styles produced code with fewer bug that I did. Using array indexes for everything instead of pointers, and other coding style issues actually reduced their bug counts. They were adhering to the KISS principal and going slow and thinking absolutely everything out before they did it.
    • As mentioned above don't hire (or at least let) overly arrogant coders to run your project. Force people to live within the constraints of your project. Don't let them tear everything apart in a weekend to add a cool feature because you will be feeling the impact for months afterwards as your locking mechanisms and other obscure things recover. If this kind of activity occurs near a release then you will feel it in the field rather than in testing. These 'great' coders who do this kind of thing may be good enough to make magic appear to happen but they aren't perfect and they may forget something small which will come back to bite them in the ass.


    Fire the C coders? (4.66 / 3) (#89)
    by treefrog on Tue Mar 12, 2002 at 05:52:49 AM EST

    Don't agree. Maybe fire the C coders who know nothing but C and carry round their dog-eardered copies of K&R. But definitely keep the ones who also have a copy of Stroustrop and maybe the Camel book or the Pickaxe book. They are the ones who understand that it is important to pick the appropriate tool for the Job.

    Let's face it. You don't really want your CGI front end for your all singing all dancing database to be written in C, but neither do you want a telecommunications radio network simulation written in anything slower than C (trust me on this one, I'm still there!).

    If the only tool you have is a hammer, then everything looks like a nail. But if you have a whole chest full of tools, then you can use a hammer when you really need to.

    Best regards, treefrog


    Twin fin swallowtail fish. You don't see many of those these days - rare as gold dust Customs officer to Treefrog
    [ Parent ]

    Right! (4.50 / 2) (#90)
    by bored on Tue Mar 12, 2002 at 11:12:29 AM EST

    I figured some one would question my K&R statement. I'm not against 'C' programmers but K&R teaches far to many bad habits. I'm much happier with a 'C' programmer who has a copy of Stroustrup (I got the spelling right :>) or a C++ programmer who restricts their use of all the bells and whistles to cases which make things clearer and/or easier.

    You are also correct about picking the right tool for the job. C++ isn't a one size fits all tool. Delphi makes wonderful tool for windows GUI development. PHP is a wonderful tool for 'CGI' type applications. etc...



    [ Parent ]
    Methodology is more important than language (5.00 / 2) (#93)
    by Lord of the Wasteland on Tue Mar 12, 2002 at 02:27:48 PM EST

    Things like exceptions were invented to solve the problem of coders who can't check return values

    The problem is, it doesn't solve the problem, it just replaces it with the problem of coders who don't handle exceptions properly. This is especially true in C++, where exceptions propagate automatically up the stack. Admittedly, Stroustrup lays down some excellent programming guidelines, but if people followed guidelines, we wouldn't have a problem. (Not that there aren't great reasons to use exceptions sometimes--they just won't save you from stupidity).

    If you really want programmers checking return values, run "lint" on their code. Then grep for (void) to make sure they haven't just used that everywhere.

    [ Parent ]

    Return values (4.00 / 1) (#95)
    by bored on Tue Mar 12, 2002 at 04:47:37 PM EST

    I don't think that return values are a good way to handle errors. The problem is that 10 function calls roll themselves into 20+ lines of code with return value error checking. This doesn't help readability. Plus lazy programmers won't check the return values until they see them fail.

    On the other hand your right, exceptions don't really solve the problem. I will simply claim that they help to solve the problem. Having a good exception strategy helps a lot. By this I mean you attempt to form transactional like systems in the code base and wrap the transaction creation routines with default error handlers that cancel the transaction. This won't work all the time but it helps. Delphi's VCL is a good example of this. Events which cause unhanded exceptions get canceled, usually right before the exception is canceled though the user is notified with a dialog box.

    As a side note the whole point of exceptions is that the problem gets propagated rather than having the code continue on its merry way. Its a lot easier to find a problem in the field when you don't have to track back through thousands of lines of code to isolate an unexpected failure. Even if the program simply crashes out with an unhanded exception notice.



    [ Parent ]
    Transactions are cool (none / 0) (#96)
    by Lord of the Wasteland on Tue Mar 12, 2002 at 05:25:23 PM EST

    Transactional programing has all sorts of cool benefits. For one thing, it makes it a lot easier to move to a multi-threaded envioronment. The difficulty is that it takes a lot of thought to design things right. A friend of mine highly recommends Exceptional C++, on this very topic, although I haven't gotten around to reading it yet.

    Just having exceptions propagate on their merry way has its own problems. It requires you code to be properly modularized, with certain levels catching all exceptions. For instance, I am always extremely agravated when some stupid uncaught NULLPointerException in a file export dialogue, say, crashes an entire Java application. Although, for debugging reasons, you're right that it is better to crash sooner rather than later if a crash is inevitable.

    [ Parent ]

    re: "Use modern ... code methods" (4.33 / 3) (#100)
    by Mysidia on Fri Mar 15, 2002 at 10:53:57 PM EST

    Use modern tools and code methods, fire the unix guy who uses pointers everywhere in his C code (and the people carrying around copies of K&R).

    C++ sucks. Guess what, pointers exist, and they are the effective means of handling many things, things like reference parameters are even more harmful than simple pointers, they create yet more kinds of mistakes to make (ie: null references!) and problems for people reviewing code being unable to discern the function call can modify its parameter (without looking up a distant prototype) and therefore not noticing some unintended side-effect that is a bug -- with C pointers it's a lot clearer [you see foo(&p) instead of foo(p)], and it's clear when the reference is local -- code can be taken in isolation without looking up other code, some C++ extensions destroy certain useful properties of the language, and many of the "new features" are "hacks" at best.. templates for example that result in redundant code insertion and bloat and increased memory usage at an extreme magnitude.

    Things like exceptions were invented to solve the problem of coders who can't check return values.

    Exceptions suck, and the point is to separate system-error-handling from implementations not to be sprinkled about mindlessly in attempts to curb laziness, they have a nasty bit of overhead to use in non-exceptional cases, and they are very evil in general because they often involve hidden, unclear, or ambiguous paths of execution and other gotchas such as part of a process needing to be reversed because another part of it failed.

    No matter how good they think they are, programmers suck, they forget shit, and if it doesn't fail during testing then it probably won't get an error check.

    Oh c'mon... programmers are only human -- do non-programmers have photographic memories or something? The more code a programmer has to work with, the more likely they are to miss something, and programmers can't be expected to have specs for things outside what they're writing memorized and all. Just like a function only does one thing at a time, the programmer can only really think about one process at one time, so the details of calling out always need extra scrutiny

    but the point of testing is to discern that the program is good enough, that it won't break.. ie, if the testing does not reveal the bugs, then there are actually two bugs, one in the program and one in the tester.

    someone didn't just decide one day to complicate C for the hell of it and add a bunch of esoteric features.

    No.. not one person, a committee of "standards" folks... representatives from corporations... management types who needed features useful for big projects (hence the appearance of namespaces)

    They concluded that the same problems were being made and solved over and over and decided that the compiler could solve them better.

    Nah... they decided they wanted this feature because they thought it would help them somehow.. some of the features (ie, operator overloading) often cause more confusion and bug propogation than they do to help the situation. Either that or they just thought it would make it harder for people other than them to write standards-compliant compilers ;-)

    those slow careful coders with the 'juvenile' coding styles produced code [...] Using array indexes for everything instead of pointers,

    I don't find this compelling, I think it's more a matter of them being more cautious.. being more careful means less likelihood of bugs, nothing to do with stylistic things like "use pointer math" vs "use arrays"... as for KISS I find '*p' to be simpler than p[0] and 'p' to be much simpler than such newbie-isms as &(p[0])



    -Mysidia the insane @k5
    [ Parent ]
    Inconsistent arguments (5.00 / 1) (#101)
    by bored on Mon Mar 18, 2002 at 07:19:31 PM EST

    I started out by pointing out your misunderstandings of C++, then I just gave up because its not worth it. You could just read the comp.std.c++ FAQ. My point wasn't that C++ didn't suck, the point I really want to make is that C is a crappy language, but it gets the job done, C++ inherits most of the crap from C, fixes a few things (stronger type checking for example) and provides you a bunch of new tools to use if needed. In some cases these tools are really useful, in others they provide a bunch of gochas that must be watched.

    being more careful means less likelihood of bugs, nothing to do with stylistic things like "use pointer math" vs "use arrays"... as for KISS I find '*p' to be simpler than p[0] and 'p' to be much simpler than such newbie-isms as &(p[0])

    I think you missed my point though, choose to ignore it, are just plain refuse to believe it, your choice. Either way, I would just like to point out the fallacy of your own argument here, its your choice if you read the many papers written on how choosing a proper style can make bugs more apparent. Above, you said "you see foo(&p) instead of foo(p)], and it's clear when the reference is local " Your right, along the same lines the extra characters to type the array and the index makes the bugs much more apparent for someone reading the code as a maintainer. So its ok to type the extra characters for a function call to make it clearer?.. but its not ok type the extra characters to make it more apparent how far into an array you are? Hmmmm...



    [ Parent ]
    bricks (3.00 / 1) (#88)
    by treefrog on Tue Mar 12, 2002 at 05:44:45 AM EST

    It's the same with code. Make your blocks small enough, strong enough, and solid enough, and the larger blocks you make with them will inherit their strength. You can do this from the bottom up through as many layers of abstraction as you need, and build arbitrarily large applications that will not crash or fail no matter what you do to them.

    If that was all you had written, the article would still be worthy of being on the Front Page.

    Best regards, treefrog


    Twin fin swallowtail fish. You don't see many of those these days - rare as gold dust Customs officer to Treefrog

    Rather silly (none / 0) (#98)
    by richieb on Wed Mar 13, 2002 at 11:07:22 PM EST

    It's the same with code. Make your blocks small enough, strong enough, and solid enough, and the larger blocks you make with them will inherit their strength. You can do this from the bottom up through as many layers of abstraction as you need, and build arbitrarily large applications that will not crash or fail no matter what you do to them.

    This is a pretty silly/vacous statement. I can build unstable structures from a bunch of bricks, no matter how strong the bricks are. For example, consider an upsidedown pyramid.

    Engineering is always a compromise between cost and strength and feasibility. So, to continue the bricks analogy, when building a structure from bricks you need bricks that are just strong enough, because the really-really strong ones cost ten times as much.

    ...richie
    It is a good day to code.
    [ Parent ]

    Large projects (4.50 / 2) (#91)
    by jmzero on Tue Mar 12, 2002 at 11:56:17 AM EST

    All the projects I deal with are small projects. Even the ones that we think of as large are really small. And we handle them as code commandos. But unlike the author of this article, I understand that large projects sometimes require a different approach. The Windows API is a large project. Have you ever heard anyone complain that Linus Torvalds can no longer handle reviewing every change? I have. And the Linux kernel is signifigantly less complicated than the "Windows API".
    There is nobody in a position to say "We're going to decide once and for all when to use variants and when to use strings, and change everything to make it consistent."
    So in one sense, the problem is "there's no standards", and in another sense the problem is "slavish" devotion to standards. What the Windows API is slave to is backwards compatibility and a desire to not write CreateWindowVer17C(). And a desire to break as few of the 30 million bits of software as possible. The Windows API NEEDS the huge buildup of process and teams. Does that result in bloated code? Yes. It also results in programs that run on Windows 95 and Windows XP without too many hiccups and without recompile (of program or OS). And MS can't just patch its old operating systems to be like its new ones, or it couldn't sell its new ones. It's easy to criticize the way MS does things, but in reality, they have some real smart people. I would love to see the author of this article put in the position of managing MS coding operations...
    .
    "Let's not stir that bag of worms." - my lovely wife
    Confessions of an Unrepentant Code Commando | 106 comments (98 topical, 8 editorial, 0 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!