Slashdot Mirror

I know, I know. They say UML is just a modelling language, it's generic, you can extend it, etc.

However, from my own experience, UML is NOT language-independent. Yes, it fits Java very well. It's OK with C++ (not the templates) and probably with Smalltalk. But it's much more difficult to map some other language ideas into the UML notation. In particular, I've seen unsuccesful attempts to use UML for:
- database-centric system with majority of logic in SQL code;
- huge system written in object-oriented Perl (yes, it's possible). Many OOPerl techniques just don't have the corresponding UML vocabulary.

For an alternative approach to modelling, look at CRC cards. It's simple and effective.

I tried this until I realized that I can't see the future. Extreme programming works much better for me. Test first, then code to pass the test case, then design by refactoring the code if necessary.

Here is an example entitled Identifying Objects: A Case Study and Class Exercise giving an example of waveform rendering on an oscilloscope (see page 5), appropriately enough based on work done at Tektronix. Is that enough of an "engineering problem" for you?

"We will create a world parallel to and embedded in the "real" world, drawing on external events, issues and objects but with its own characters, events and objects. This world will exist primarily in the Internet, but it will occasionally reach into people's lives through a wide variety of media - including faxes, telephone calls and live acting."

Hopefully, they won't need "death threats" to make their World entertaining.

Stephan

PS: I am not affiliated with that group, except for the fact that they're using my Wiki farm to host their own Wiki.

PS2: A Wiki is a collaborative web site that can be edited and organized by its visitors. See the original Wiki Wiki Web invented by Ward Cunningham.

"Learning curve" doesn't mean what you think it means.

About the only ways to get post-60's/70's into most backend business systems is to either start with it (still get same out-of-date problem in five, ten or fifteen years) or to have the higher-ups declare that a particular system will be used. Too bad a lot of Linux companies are getting a bad rap. If the hype had kept going, a lot of higher-ups would probably have switched to *Open Source* systems just to be the first in their country club to have all-Linux accounting department.

Sorry about the cynicism but I've worked with migrating few small inventory and accounting systems to something from the 90's and none of them were pretty from the personal or technical point of view. Sometimes it's all about culture.

I read Joel's original article on this subject("Things You Should Never Do, Part I") a few months ago. Despite the rampant /. kiddie practice of posting a strong opinion without reading the article being referenced, I encourage you to read it now:

Things You Should Never Do, Part I

OK, so you didn't read it, I'll quote a juicy part: "You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration."

The point is that if you have all the time and money in the world, of course you should rewrite from scratch when things get yucky. The problem is that in the real world, companies need new releases to keep selling upgrades, so you need to keep steadily improving the product. Similarly, customers adopt the product, use it a bit, and then learn what they want next - they want to invest in the product more. Meanwhile, the purist coders at the vendor are busy taking three years to make the architecture pretty, which will pay off big-time in year 4 and 5 when they'll be able to add new features at a breathtaking pace. Customers get pissed and go find someone who will sell them a product which is about as buggy as the one the first company made, but which now has a few key features.

Coders don't necessarily understand the sales angle of this, because they're trying to avoid inefficiencies in development, such as wasting time hacking on a crufty code base to try and add a feature. They'd rather invest early and reap rewards later. The problem is, most software companies don't have the luxury of investing heavily from a payroll standpoint, not even considering the customer attrition problem.

As a perfectionist myself, I really hate the fact that this is true, but it is. Business realities suck sometimes. There's a sci-fi business parable about this...

Two space empires are at war. One side is starting to lose, but one day their leader announces that they will soon be victorious! Their scientists are working on a doomsday device which will wipe out the enemy. Time passes and the war is going badly, but no one is worried about the heavy casualties because they know they will win any day now. Planet after planet is captured, ship after ship destroyed. Finally, one day the lead scientist who is working on the homeworld screams "Eureka!" because he knows that the device finally works. He races to the office of the imperial leader and bursts in, full of excitement, only to see enemy soldiers standing over him with guns drawn as he signs his name to articles of surrender, because they've lost.

Unfortunately for the scientist and his empire, they didn't think to refactor, or design APIs between modules... :) If they had they'd be able to clean things up module by module, because they designed robust APIs early and then wrote quick and dirty implementations that could be fixed later when there was both time and need.

eXtreme Programming has some interesting things to say about this too. Basically, don't implement anything that isn't in the requirements now (that is, don't overgeneralize to a fancy-pants API and module system if you're only gonna write one module on top of that API), also known as DoTheSimplestThingThatCouldPossiblyWork, and RefactorMercilessly to clean up code continuously as you maintain it.

Finally, remember that testing makes maintenance immeasurably easier. The reason that maintenance sucks so bad is usually that some cowboy coder thought that documentation is what you do when the code is finished, which of course (a) is wrong and (b) never actually happens. If docs are demanded up front, including test cases, coding is much easier as is maintenance, and you don't have to bite your fingernails wondering if your tiny bug fix un-fixed 100 other "fixed" bugs. If you have tests, you can RefactorMercilessly and rip out the most egregiously gross code, and get it all back together and working, without it blowing up in your face. So make sure somebody writes a basic spec, then write test cases and code that performs them so you can code with impunity and so you can go on vacation :)

I read Joel's original article on this subject("Things You Should Never Do, Part I") a few months ago. Despite the rampant /. kiddie practice of posting a strong opinion without reading the article being referenced, I encourage you to read it now:

Things You Should Never Do, Part I

OK, so you didn't read it, I'll quote a juicy part: "You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration."

The point is that if you have all the time and money in the world, of course you should rewrite from scratch when things get yucky. The problem is that in the real world, companies need new releases to keep selling upgrades, so you need to keep steadily improving the product. Similarly, customers adopt the product, use it a bit, and then learn what they want next - they want to invest in the product more. Meanwhile, the purist coders at the vendor are busy taking three years to make the architecture pretty, which will pay off big-time in year 4 and 5 when they'll be able to add new features at a breathtaking pace. Customers get pissed and go find someone who will sell them a product which is about as buggy as the one the first company made, but which now has a few key features.

Coders don't necessarily understand the sales angle of this, because they're trying to avoid inefficiencies in development, such as wasting time hacking on a crufty code base to try and add a feature. They'd rather invest early and reap rewards later. The problem is, most software companies don't have the luxury of investing heavily from a payroll standpoint, not even considering the customer attrition problem.

As a perfectionist myself, I really hate the fact that this is true, but it is. Business realities suck sometimes. There's a sci-fi business parable about this...

Two space empires are at war. One side is starting to lose, but one day their leader announces that they will soon be victorious! Their scientists are working on a doomsday device which will wipe out the enemy. Time passes and the war is going badly, but no one is worried about the heavy casualties because they know they will win any day now. Planet after planet is captured, ship after ship destroyed. Finally, one day the lead scientist who is working on the homeworld screams "Eureka!" because he knows that the device finally works. He races to the office of the imperial leader and bursts in, full of excitement, only to see enemy soldiers standing over him with guns drawn as he signs his name to articles of surrender, because they've lost.

Unfortunately for the scientist and his empire, they didn't think to refactor, or design APIs between modules... :) If they had they'd be able to clean things up module by module, because they designed robust APIs early and then wrote quick and dirty implementations that could be fixed later when there was both time and need.

eXtreme Programming has some interesting things to say about this too. Basically, don't implement anything that isn't in the requirements now (that is, don't overgeneralize to a fancy-pants API and module system if you're only gonna write one module on top of that API), also known as DoTheSimplestThingThatCouldPossiblyWork, and RefactorMercilessly to clean up code continuously as you maintain it.

Finally, remember that testing makes maintenance immeasurably easier. The reason that maintenance sucks so bad is usually that some cowboy coder thought that documentation is what you do when the code is finished, which of course (a) is wrong and (b) never actually happens. If docs are demanded up front, including test cases, coding is much easier as is maintenance, and you don't have to bite your fingernails wondering if your tiny bug fix un-fixed 100 other "fixed" bugs. If you have tests, you can RefactorMercilessly and rip out the most egregiously gross code, and get it all back together and working, without it blowing up in your face. So make sure somebody writes a basic spec, then write test cases and code that performs them so you can code with impunity and so you can go on vacation :)

Yes, there is often a happy medium between completely rewriting the whole codebase and continuing to hack it up. There have always been disciplined ways to steadily improve existing code over time.

The latest buzzword for this is Refactoring. There are some excellent published materials on this topic. We've finally reached a stage where verbal discussion of good software engineering techniques have reached a point where we can write intelligently about the topic using common terminology. See refactoring.com and The First Wiki for some good online starting-points.

Someone should start a wiki wiki web (a page modifiable by anyone, a la Wikipedia) for people to post information they find about this little bastard. Eventually, enough info should come together to allow writing a specific detection utility, which could then be slashdotted. I would do it myself, but I don't have a server (I'm in Romania).

Well, guess what, Linux is pretty darn big and yep it's written in lots of languages. And Corba is built to let you do the same kind of thing for big systems. As long as you aren't building a time bomb maintenance-wise, you should consider carefully the post above about the design pattern for alternation of hard and soft layers. It's not cut and dry.

I just posted in a previous thread reasoning about using Perl in a large project. For one thing, Perl is already a big system and it is written in Perl, C, C++, and whatever else you may want. You can call object code modules from Perl, wrap them in Perl Modules, and even write code from other languages inline inside your Perl programs (compiled automatically).

I do think you should seriously consider scrapping PHP. It is really not that great and if you are using Perl there is no excuse not to separate design from code. Also it is backwards to control Perl, a high-level language, with C++, a low-level language. The final answer is that there are valid systems for both multi-language and single-language implementations, but your choice is likely to have a big effect on the performance, maintainability, packability, and development schedule/paradigm so think hard about it! (But please stop lobotomizing Perl by calling it from C++!)

This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:

By virtue of the FirstRuleOfOptimization, go ahead and write most of your code in the highest level language you can find.

By virtue of the ThirdRuleOfOptimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.

In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.

Lately I've found that using SWIG makes this pattern very easy to apply in real life.

This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:

By virtue of the FirstRuleOfOptimization, go ahead and write most of your code in the highest level language you can find.

By virtue of the ThirdRuleOfOptimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.

In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.

Lately I've found that using SWIG makes this pattern very easy to apply in real life.

This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:

By virtue of the FirstRuleOfOptimization, go ahead and write most of your code in the highest level language you can find.

By virtue of the ThirdRuleOfOptimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.

In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.

Lately I've found that using SWIG makes this pattern very easy to apply in real life.

This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:

By virtue of the FirstRuleOfOptimization, go ahead and write most of your code in the highest level language you can find.

By virtue of the ThirdRuleOfOptimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.

In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.

Lately I've found that using SWIG makes this pattern very easy to apply in real life.

This approach to software has been codified into a Design Pattern: Alternate Hard and Soft Layers. From the WikiWiki page:

By virtue of the FirstRuleOfOptimization, go ahead and write most of your code in the highest level language you can find.

By virtue of the ThirdRuleOfOptimization, when you must, use a profiler and find the slow parts of your program. Take those parts, and write them in a lower-level language.

In other words, use a "soft", dynamic language for the parts of your program that may change, and that don't require extreme effeciency. Use "hard", static, compiled languages for the parts of the program that must run as fast as possible; or that need to do low-level memory-twiddling. To put it even more succinctly, use the right tool for the right job.

Lately I've found that using SWIG makes this pattern very easy to apply in real life.

Of course now, it's so easy to create jaw dropping images without optimized code [...] I miss seeing elegant code.

Although the size of code could be a good metric for elegance (it could for instance be a good indication of RapeAndPasteProgramming), I would never equate optimized code with elegant code. Optimization generally cuts corners and does other nasty things that wreak havoc with the original design of the code.

OTOH, the real reason why I am taking this now is because they already have this same question posted since more than one year ago here. Maybe you find this useful. They have the best books of some personalities (Alistair Cockburn, Michael Feathers, and so on).

The deleted Tron love scene? An interview with Alan Kay?

There is a real issue here, though:

Who pays for the transport, i.e., the backbone? In the early post-ARPA days, the National Science Foundation paid for the backbone, through a project called NFSNET. However, because NSF didn't feel it was appropriate for the government (yes, the same government so many /.ers love to hate) to pay for the bandwidth for commercial intents, the backbone was transferred to private operation. I think this was a huge mistake. A global information network is fundamentally a public good, and ultimate control of it should reside with the public, not private enterprise. People looking to make money should pay to use a public medium to do so, but control of the medium should belong to the public, much like the FCC licensing bandwidth.

If we really are in a free market (which I doubt, because they don't exist), then as long as there's a substantive demand for free information, someone should want to sell it to us. But I do think it will be hard for anyone to match the kind of money that media giants or B2B powerhouses can throw at having routing done their way.

This brief history of the Internet is good reading. It includes a definition of the word Internet. Perhaps there could be publicly controlled routers managed by wiki?

Java is a nifty platform, but unfortunately it requires that you do all of your programming in Java the language.

Err, not really. See:

• Programming Languages for the Java Virtual Machine
• Other Languages For The Java VM on WikiWikiWeb

Java is a nifty platform, but unfortunately it requires that you do all of your programming in Java the language.

Err, not really. See:

• Programming Languages for the Java Virtual Machine
• Other Languages For The Java VM on WikiWikiWeb

No, the analogy stands. For example, why doesn't all business application development get done in COBOL, or FORTRAN, or C, or C++? Because newer languages are more productive. They have substantial improvements in areas like automatic memory management, type safety, etc. There's no question that we've had significant advances in programming languages, so the only thing you can really argue is whether we've somehow reached a final plateau of language efficiency. Even a small amount of research into past, current, and cutting-edge language features makes it clear that this is highly unlikely to be the case.

You seem to think that functional languages are somehow more "advanced" than procedural languages. There is no objective reason to support this conclusion -- it is like saying chocolate ice cream is more advanced than strawberry

There are plenty of objective reasons, but they probably go beyond the scope of a /. discussion. I come across these time and again as I move between commercial work in languages like Java and C++, and other projects in languages like Scheme and ML. First-order procedures are a good example: the lack of these in languages like Java and Visual BASIC makes all sorts of tasks much more difficult, requires more code, and may even require code generation to achieve dynamic behavior.

In fact, it can be argued that many of the more advanced features in modern programming language derive from functional roots - see Mainstream Influence Of Functional Languages. The reason for this is that the mathematical formalism behind functional programming, e.g. the lambda calculus, provide a far more consistent basis for the development of higher-level features than the ad-hoc design of many older programming languages.

All of them (sans a few mini-languages) are Turing complete and so are objectively exactly the same.

This is such a common claim that you'd think people would have figured out how meaningless it is by now. As another poster mentioned, Unlambda and Intercal are also Turing complete, and their existence alone effectively disproves your argument. However, to make it clearer, I'll go back to my analogy: all methods of transportation are equally capable of getting you from point A to point B. The question is how long it will take, and how much effort you will have to expend to get there. Advances in programming languages are quite closely analogous.

I *know* that new languages can't really make me more productive

How do you know this? And which languages do you know? If you've never experienced the productivity differences between different languages, you can't be familiar with much of a variety of them.

They say if its useful to do code reviews, it should be useful to do them all the time. ie. Pair programming.

They claim to have evidence that it works better in the long run than anything else...

Reducing fan noise in your PC

GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.

The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.

KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.

GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.

The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.

KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.

GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.

The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.

KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.

GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.

The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.

KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.

GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.

The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.

KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.

GNOME folks took the approach of doing BigDesignUpfront while the KDE crowd concentrated on doing today's job today and leaving tomorrow's job for tomorrow. As a result their project progressed faster and they let their architecture emerge from the changing requirements. Hence they've changed the project management to a more agile model akin to that of ExtremeProgramming. I believe this approach is superior.

The prime example of the fundamental differences between the two project was the design of their component models where the GNOME team took eons to refine and polish Bonobo even though the didn't know upfornt what they'd use it for while the KDE team who admittedly took a similar approach with OpenParts they had the Courage to overthrow their flawed design and go with the SimplestThingThatCouldPossiblyWork. The situation with their widget toolkit was analogous: while the GNOME team made the politically correct decision at the time the KDE crew decided to go with the toolkit that gave them the highest productivity rate instead of sufffering from the NotInventedHere syndrome. If GNOME folks carry on like this making big (and often incorrect) decisions early in the project they will disintegrate just like many commercial projects do. And believe me I witnessed more than one Big Design that just crumbled and disintegrated under the pressure of everchanging requirements of a large software project.

KDE folk are definitely ahead of the game as they have a more agile development model. If only they paid more attention to UnitTests they would progress even faster IMNSHO.

You're quite correct that I haven't used it to meet a deadline like you describe. That is probably because my employers have always trusted me to set my own schedule, and I make sure I do it right. Part of doing it right for me is staying far away from the Microsoft Incompatible Dependency Suite.

Yes! Anyone who's interested in working on a free/open source WikiBrowser (WardsWiki) WikiBrowser (Meatball) go read and contribute at those links, or contact me. It could be done as a sidebar in browsers that do that, and as a separate app for different OSes. (there's no project yet)

Life,
John

>> It will be like an analog version of Slashdot.

It'd be more like a physical version of Wiki.

Personally, I'd just use the blackboard to do math problems.

As another poster wrote, this is because they usually aren't asked to estimate their tasks. Lots of times, their managers estimate their tasks for them!

What would happen if we kept the sizes of the things developers had to estimate down to a reasonable size, like a few weeks. Then we asked them to estimate these things fairly often, as new stories are written. Pretty quickly, the developers would build up a history of how their estimates matched reality. They could then start estimating new stories based on relative sizes with things previously done.

Given the rapid buildup of history, and the small sizes of the chunks, the estimates get pretty good pretty fast

At a higher level, most developers don't have any idea how long it will take them to develop the feature spec.

One reason for this is because there is no way to tell when you are done. How do you test a feature spec for completeness? For accuracy? For bugs?

What if we let the customer write down as many features as they wanted, allowed them to add features at any time, and gave them rough estimates on what those features cost? We wouldn't care how long the whole spec took to write, because it would be evolving as the customer's understanding of the system evolved. And as business conditions changed, and the requirements for the system changed, the customer would be free to change their mind, without incurring exorbitant costs. Customers love this!

If you are talking about end-to-end tests of a feature, then that is the responsibility of the customer, along with QA. As customers decided that certain stories were the highest priority things to work on, they would have to come up with a verifiable set of acceptance tests that would both define the acceptance criteria for that story, and also provide detailed, executable requirements. Programmers could now tell, in a binary manner, if they were finished with a feature or not!

If you are talking about unit tests, the developer simply writes the most appropriate test at the most appropriate time, and you end up with almost 100% code coverage automatically. You'll have to read more about TestFirstDesign to understand more fully what I'm talking about here.

Disclaimer: I am an Xp coach, and I teach teams to do this for a living. It works. It really does :)

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

WikiWikiWeb has a lot of pages about Extreme Programming. Like how to get there, why you shouldn't go, and how not to get stuck along the way.
--

If you understand and are comfortable with Simula there is the Smalltalk-72 emulation [1] created by Dan Ingalls you can file into Squeak.

Doug Engelbert pioneered the use of Graphic Human Tool Interface with bitmap displays starting in 1957 and going public with his oNLine System in the "MotherOfAllDemos" in 1968.

• [1] Smalltalk-72 ChangeSet for Squeak
  ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/goodies/ Smalltalk-72/
• [2] WikiWiki:TheMotherOfAllDemos
  http://www.c2.com/cgi/wiki?TheMotherOfAllDemos
• [3] RealAudio copy of the MotherOfAllDemos
  http://sloan.stanford.edu/MouseSite/1968Demo.html
• [4] The Augmented Knowlege Workshop - Chronology - 1964
  http://www.bootstrap.org/augment-101931.htm#6C

Extreme Programming. The extreme programming (XP) methodology grew out of a Smalltalk project 3-4 years ago. The founder of extreme programming, Kent Beck, advocates Smalltalk as the most productive language for XP, as does Ron Jeffries, the author of the Extreme Programming Installed book.

Refactoring. The term "refactoring" has become popular in the last few years, due in large part to the work done on the Refactoring Browser for Smalltalk by John Brant and Don Roberts. (Martin Fowler's book on Refactoring includes a section on the Refactoring Browser.) The Refactoring Browser lets you perform automated behavior-preserving code refactorings, such as abstracting references to an instance variable, pushing a method up into its superclass, etc. (There have also been some refactoring tools written for Java, but the nature of the Java language will make it difficult to create a tool as powerful as the Refactoring Browser for Smalltalk.)

IDE's (Integrated Development Environments). Smalltalk has generally been considered a leader in this area, with its integrated code browsers, the ability to reliably look up all senders or implementors of a method, etc. (There is the occasional effort in other languages to catch up in this area, such as VisualAge Java with its integrated browsers, but VA/Java was also written in Smalltalk.) Also, to shamelessy toot my own horn for a minute, I've created an object-oriented "stacking" code browser for Squeak/Smalltalk called Whisker. I used Smalltalk to create this because the IDE supports this sort of experimentation well.

So, to claim that Smalltalk is somehow dead or obsolete is obviously false. True, it doesn't have the marketing hype (and market penetration) that Java does, but then, what else does? :-)

(Also, I still consider the language features of Smalltalk to be more technically "advanced" than those of Java. My personal hunch is that if you conducted a random poll of developers with *significant* experience with both languages (say, a minimum of 1 year full-time experience with each), probably 90-98% would agree with this. Of course, the same is probably true of Scheme vs. Java, or CLOS vs. Java, etc.)

Anyway, Smalltalk is obviously not the answer to all programming problems. (I wouldn't use it to write a device driver, for example.) But it is still one of the best (if not *the* best) options for many larger programming problems.

I've only used UML a few times, so more experience practitioners may have different experiences, but I'm not a big fan. Firstly there is the ambiguity of UML - not necessarily the ambiguity of the language it's self - but in the way people interpret it. I can't really show a client a use-case diagram and ask them if it's correct, and each developer you show a diagram to seems to have a slightly different interpretation of how the system should function. I know this problem arises with any form of communication but the simplicity of boxes and arrows coupled with the familiarity of written communication would probably result in less ambiguity and confusion. Secondly, the UML tool I've used (Visio Enterprise) was really crap. Here's some of the reasons the people over at Wiki consider UML Harmful