Tuesday, December 06, 2005

The need for speed...

The need for speed. Or not. It seems to be coming up more frequently or maybe I’m just getting more annoyed by it. “No time to do it right, always time to do it over”. That phrase is also known today by the euphemism “refactoring”. ‘Extreme Programming’ and ‘Agile Development’. Extreme programming (XP) isn’t so bad but it does claim to be brand new (saying it was invented 7 years ago). Funny, but I remember using a process that looked suspiciously like that almost 20 years ago. Sure, we didn’t call it that but it sure followed the same path. Programmers were at least paired up, sitting in the same room (we had rooms with doors back then), working together. Typically in a Jr/Sr developer pattern (mentorship was a big deal at the company I started with fortunately). Regular peer reviews. Incremental releases to the end user. Unit testing. It had everything but the name.

Recently, there has a been a thread on Asktom regarding XP and that it removed the need to have comments/documentation of the code. I’m afraid I’m in total disagreement with that concept. The theory is “the how and the why of the code is known in part by the entire development team and we will pass this knowledge down from generation to generation by word of mouth. XP makes the code (due to coding standards) so readable, comments are no long necessary”. I just very much disagree. One of the come backs was “well, comments are frequently out of date with the code”. That to me is a failure of your coding standards and peer review process then – if your standards for coding are so good that the “code is the comment”, then your standards for coding can ensure the comments/documentation are up to date as well.

Additionally, there is sometimes a huge difference between what the code does and what the code was actually intended to do. These are referred to as bugs usually. The code might be incredibly readable, but if the code isn’t doing what it was truly intended to do – so what? We need some commentary as to what the code was to accomplish. I’ve seen that many times before. In fact, someone just put up a pretty good example of that.

Then there is Agile Development. It has a time and place, but to use it everywhere is wrong. I bring this up because of two recent blog entries I just read. The first is by Kathy Sierra – on the need to slow down sometimes… I’m like her, I work on 10 things at once (attention span of a fly sometimes) usually – but for some things, you just have to sit down and plod through it slowly. Writing a chapter in a book comes to mind. That is something I just have to do from start to finish, slowly, in sequence, with a plan. The other blog was more to the point. “Agile Programming”, when applied inappropriately, is a mess. Worse than a mess, a disaster.

There are many kinds of software out there, there is no one size fits all from a development strategy. There are many kinds of tools out there, there is no one size fits all. There are many , there is no one size fits all.

In closing – Never say Never, Never say Always, I Always say. Figure that one out.

And just for fun… A quick movie that made me laugh.


Blogger melanie caffrey said....

A quick movie that made me laugh.

Ah, more internet viro videos.

You probably laughed at that because, no doubt, you were already a fan of this oldie, but goodie.



Tue Dec 06, 10:01:00 AM EST  

Blogger melanie caffrey said....


This should make it easier.

breaking computer

Tue Dec 06, 10:06:00 AM EST  

Anonymous Anonymous said....

Back in 1993, when I started, we used RAD/JAD - Rapid Application Development / Joint Application Development.

This meant we worked in iterative releases, adding functionality, and reviewing with the customer each release. We worked in mentor pairs and small teams.

Apart from the 'don't worry about rework' part, this is identical to Agile/XP. Quite frankly, I believe that that is the worst part of Agile/XP and I hate it - the project I'm on is just reworking about 20% of the codebase because (it turns out) not enough 'ask, ask, ask' was done at the start. Myself, I don't start coding till I run out of questions. More questions do occur to me(!), but until I at least *think* I understand fully, I shouldn't be writing code.



Tue Dec 06, 10:08:00 AM EST  

Blogger shrek said....

the problem is to use whatever method to give the end users what they need and not what they want.;-)

Tue Dec 06, 10:08:00 AM EST  

Blogger Bill S. said....

As a developer if the code wasn't commented, I didn't want to touch it. Reason? I have no clue what is original code and what is some mod that was added after the fact. I was taught to not only comment my code, but include my initials and the date I added the comment. People that don't comment code are people that like to cause migrains in their fellow developers. IMHO, of course.

Word verification:
Hmm.....try prozac? Sure! Just found some uncommented code!

Tue Dec 06, 12:05:00 PM EST  

Blogger Jeff Hunter said....

Back when I wrote code (when "C" was hot), I was brought up with the "Just get it done" methodology. Commenting was necessary because when you revisited the code two years later you forgot what it did. I'm glad I don't do that anymore.

my word: lyixfqbr - wasn't that a superman's arch enemy?

Tue Dec 06, 12:58:00 PM EST  

Anonymous Bob B said....

Commenting the why is critical. Like Tom said, if the how doesn't match the why, that's what is generally known as a "bug". Without a why comment, you'll often be left trying to figure out if something was a bug or intentional.

For example, I saw this in some pl/sql code.

v_some_var = NULL OR
v_some_var = 0

v_some_var = NULL has no boolean value. The programmer probably meant "v_some_var IS NULL", but should I follow what the programmer meant or what the programmer said?

So without the comment on why, I'm left choosing between possibly creating a bug and possibly not removing a bug.

Tue Dec 06, 01:22:00 PM EST  

Anonymous Krous said....

But then maybe you DO want it obfuscated..

Tue Dec 06, 07:26:00 PM EST  

Anonymous Anonymous said....

Is this NetOp Desktop Firewall safe to install.

Let me know if anyone tried it.


Wed Dec 07, 01:43:00 AM EST  

Blogger Thomas Kyte said....

Note: I am not trying to say anything about Netop firewall, just stumbled upon the video and found it funny.

Wed Dec 07, 01:44:00 AM EST  

Anonymous Anonymous said....

Are you awake this late? Guessing which part of the world are you in now !!!

Wed Dec 07, 01:49:00 AM EST  

Blogger Thomas Kyte said....

No need to guess, my speaking schedule is on asktom ;) I'm in Zurich right now getting ready to get started for the day.

Wed Dec 07, 01:51:00 AM EST  

Anonymous øyvind said....

Forgot to thank you for the seminar in Oslo (5th). Enjoyed it as I did last time you were here.

Wed Dec 07, 05:21:00 AM EST  

Anonymous Bob B said....

This discussion is reminding me of the Story of Alexandria that I read on the straight dope recently.

Back in BC Egypt, the paper they used to write things down on (papyrus) wasn't designed to last forever. In order to preserve the scripts over the years, scribes would have to transcribe entire texts by hand.

With a few texts, this maintenance isn't a problem. As the Great Library of Alexandria got larger, the sheer amount of work needed to transcribe texts was too much. Eventually some texts were deemed unimportant and were lost.

I forsee a similar demise for any company that thinks it can get away by passing documentation down by word of mouth. At some point, they'll have to choose between losing information and making progress.

Wed Dec 07, 10:13:00 AM EST  

Anonymous oraboy said....

On the same topic (commenting and its significance) , I came across this link

/// The GaidenCommand is a specialized Command for use by the
/// CommandManager.
/// Note, the word "gaiden" is Japanese and means "side story",
/// see "http://en.wikipedia.org/wiki/Gaiden".
/// Why did I call this "GaidenCommand"? Because it's very similar to
/// a regular Command, but it serves the CommandManager in a different
/// way, and it is not the same as a regular "Command". Also
/// "CommandManagerCommand" is far too long to write. I also toyed with
/// calling this the "AlephCommand", Aleph being a silent Hebrew
/// letter, but Gaiden sounded better.

* This source-code is to only be used by Initech developers. So that someone
* may navigate through this source code, here is the convention used:
* - All variable and function names are in English (for the most part), so that
* it will be clear for programmers; the names speak for themselves.
* - Comments throughout the code are usually written in French. If you don't
* speak French, and cannot find us to ask what a comment means, you can use
* a grammatical translator online, like http://www.systransoft.com

hope you enjoy it

word verification: emdjtom (hmm..competitor to asktom ?)

Wed Dec 07, 11:55:00 AM EST  

Anonymous Andrew said....

I remember when I worked at a very large manufacturing company a number of years ago, the running joke was that their project management methodology was.
o Ready
o Fire
o Aim

I bet there are alot of firms out there that still work that way.

Thu Dec 08, 05:02:00 PM EST  

Anonymous Anonymous said....

Under our current company leadership, it's exactly that. Do it quickly. No matter if you do it poorly, wrong, or unmanagable. Just put out screens. He'll be retired in a couple of years, and his legacy will be 10x the chaos of the last 2. I'll probably retire myself before our company digs itself out. Our technology division has gone from being a repected wing to a laughing stock. Not bad for 2 years of "Do it fast"

Thu Dec 08, 08:13:00 PM EST  

Anonymous Anonymous said....

I can judge the potential success of a software project in 5 minutes and it has nothing to do with programming languages or database platforms.

Show me your requirements document. Show me a programming specification document. Show me your project plan. Show me your testing plan.

Fri Dec 09, 09:19:00 AM EST  

Anonymous Anonymous said....

While speed is very important and usually essential, accuracy is more important in software engineering and quality. Besides, if NASA, for instance, was more focused on speed than in accuracy in strategic decision making, and expanded via requirements engineering, then XP would be the appropriate SE philosophy over traditional SDLC methodologies and tools. However, would this strategy make it consistent with the risk of going into space or simply launching a spaceship with rocket? How about the detail testing of all the laws of physics? Outstanding programmers and software engineers could accomplish even large projects in record time, yet the risk of the human error could still be there, like in the well-known FORTRAN loop line. This was not about the CMM model. I think that Oracle’s vision with BPEL and JDeveloper will have an enormous impact when these tools integrate with Designer, Discoverer, and BI Beans among other valuable incremental software development paradigm. ADN

Sat Dec 10, 09:48:00 AM EST  

Blogger Urban said....

Programmers should think of themselves as writers writing a book. Your code will be read over and over so you better make it readable AND understandable. XP and Agile is more like the draft...

Mon Dec 12, 03:09:00 AM EST  

Anonymous Andrew Limsk said....

We all want to get that project up and running as quick as possible, but an ounce of sweat during the initial design and creation is going to save a gallon of blood several years down the road.

Back in the 1990's the company I worked for (a large financial institution) had a godzilla RPG/400 day-end batch program that subscribed to the "less is better" school of code commenting.

All the programmers in the shop lived in terror of the day we would be assigned the task to modify it especially since its failure had already claimed several career casualties. Simple changes took a week of code study. Complex changes took several months.

During one such change, the development team assigned the unenviable task went to considerable (and possibly borderline illegal) effort to track down the guy who created the monster and added a few extra lines that inserted this generic comment into the messages from the error handling routines "ERROR: Yup, another bloody error. Please call XXXXXXXXXXX phone xxx-xxxxxxxx to thank him for his exemplary coding philosophy"

Wed Dec 14, 04:10:00 AM EST  

Blogger John Harper said....


I read your, “Need for Speed,” blog article and the comments that were in your, “The 10 (Oracle Development) Commandments,” article on AskTom. I really liked the sound advice that you and others gave.

I agree that XP, Agile, etc… are just aliases for the same methods.

One of the overwhelming problems I see with our “NEW” agile discipline is that developers, architects, and program managers use it as an excuse to write really bad code. In my experience, writing functional based code without looking at the big picture causes disparate systems that are (down the road) VERY difficult AND EXPENSIVE to manage; however, as we are in the throws of “Agile” **cough, cough, hacking, cough ** programming, I would like to read up on the methods in detail, so that I may properly discern between good and bad agile methods.

Please suggest some good books….

Thank you,

Wed Aug 16, 01:25:00 PM EDT  

Blogger John Harper said....

Your comment that XP is the rough draft doesn't make sense. In reality the whole point behind XP is get the right people in the same room together, outline what is important, then code stuff, as a team.

It does not mean hack, rough draft, or partial. Note that Ron Jefferies states that the story has to be defined. Its a lot like a movie story board. Once the whole picture is defined, the project team cuts out the not important stuff and codes the rest.

It does have one weakness, that is, it is easy for one to become side-tracked. The program manager MUST have a strong vision of what the customer needs and how his/her program works laterally (not just functionally - vertically)... otherwise, one ends up with a ginormous mess of functional silos and disparate systems that are ALOT more expensive than traditional, waterfall products.

I just picked up two books: "Extreme Programming Installed" and "Test-Driven Development." They seem to be fairly good books. Ron Jeffries clearly states that XP is not a slash and burn or code and fix process.

I think half of the people using XP or Agile don't know what the heck they are talking about. They use it as an excuse to hack. Maybe it's that same half that give XP a bad name.

Tue Sep 05, 05:07:00 PM EDT  

Anonymous Anonymous said....

Very Good article , this article make some interesting points.
Tactical Flashlights
r c helicopter
video game
Tactical Flashlight

Mon Jun 23, 02:36:00 AM EDT  


<< Home