Slashdot Mirror

Management at my company seems to think that our developers can get extra work done if they work extra long days.

When I managed software engineers, I used to walk around and tell them to go home. The software engineers need the time to refresh, just as an athlete needs time to rejuvenate.

.
Here's a good article on the topic.

One of the main things you should be doing when practicing agile is continuous integration. The point is that you should be able to release at the drop of a hat.

That's one of the problems with these self-reported "Agile" failures - sure, it borders on a no true Scotsman argument, but if you're "doing agile" with five or six week "sprints", hour-long sit-down meetings instead of standups, no product manager, no backlog, no continuous integration - then can you really say that agile methodologies failed?

What really happened was you were trying to do waterfall faster, which just doesn't work. It's like saying baseball doesn't work because you made a few "tweaks".

JOINs just don't scale. You can distribute data across any number of nodes, but JOINing data which lives on separate computers is not gonna happen.

If that's the case, then surely we're Doing Something Really Wrong with our implementation of relational theory. Should we perhaps be looking at things like Extended Set Theory instead?

Relational - (and more specifically, SQL, which as Chris Date is at pains to tell every is NOT even a correct let alone good implementation of the relational model - but even Codd's original paper shows signs of this) - came out of a timesharing environment, where it was just assumed as a matter of course that you'd have very large datasets sitting on single giant machines. And out of that environment came the 'database server' concept we're familiar with today.

The problem is that in the age of the Web, more and more our data IS distributed among thousands if not millions of nodes. This is especially obvious in social networking - at the moment, we're very obviously Doing It Wrong by relying on huge centralised mega-stores like Facebook. We should be asking why this is, and how our tools can be improved to stop forcing us toward a centralised model when decentralised is what we clearly need.

It seems to me that in a massively decentralised model, it ought to be easy enough to have multi-dataset JOINs or some equivalent. We just have to implement a way of caching the results and transmitting only the changes, in a store-forward-publish model.

  Ie, a decentralised JOIN (or any other dataset filter) shouldn't be an 'operation' which runs, connects to lots of datasources, transmits/receives huge amounts of information, processes it into a subset, hands it on and then disconnects, throwing away all that data. That model is still harking back to the old batch processing days of mainframes. Instead, a JOIN should be a sort of object: you create a new derived dataset entity which connects ONCE to all its sources, grabs what it needs, then CACHES its data locally so it doesn't consume bandwidth.

This would let us create a truly decentralised 'web of data' - a bit like the old Usenet model, but for data not next - where you subscribe to datasets, receive just the updates, do whatever filtering or processing you want on the updates as they come in, and present your derived view - a bit like a SQL 'View' but far more general and able to do arbitrary Turing-complete processing.

I dunno who's working on this but it seems obvious that we need something like that. Huge centralised 'databases' are just so foreign to the Web model that I don't know why we still force people to use them.

You can't create quality software without ... testing after coding.

Yes you can. You can test before coding.

• the practice is not as good as you think
• they don't yet see why the practice is good
• their workload is too high, leaving no time or enthusiasm for learning and exploring
• in the past you have done other top-down imposition that have undermined the morale and the sense of ownership needed for changes like this

1. Ask for what you actually want: fewer bugs.
2. Use a Big Visible Chart (yes, paper; yes, hand-drawn; yes, on the wall in a shared space where everybody will see it regularly) to make a bug metric visible.
3. Ask the developers how to achieve your goal. Unit testing will be one of the answers.
4. Ask for a team or project that would like to volunteer to try out unit testing and figure out how to make it work in your environment.
5. Ask them what it will take to make that a reality.
6. Give them what they ask for. All of it. No pressure, no whining about the cost.
7. Come back weekly to ask them how it's going and what you can do to help.

Really, wtf?!? Who comes up with this shite!?!

Extreme Programming was invented by programmers; they felt it was the best way for them to work on the project they were doing. All of the main Extreme Programming proponents still write code regularly, and some even blog in detail about coding.

I'm a programmer, and I love it. If you want to know why, don't hesitate to ask.

Actually what you are saying is completely not true when it comes to XP. They clearly say in their docs that you can choose the pieces of the methodology that you feel valuable and leave out ones you don't use.

It also was extracted from a real world project methodology used by the C3 project. So in fact this methodology came from real world practices, not out of someone's ass as you imply:

http://www.xprogramming.com/Practices/xpractices.h tm

I've been in environments where we've used XP, I've been in environments where we used CMM (level 5!), and I've been in environments were we used nothing at all. IMO, most practices of XP are solid and can be used well in the real world. For instance unit testing gained popularity via XP. That's a good thing. Continuous building, something that large projects have been using for years, is a good practice. Etc.

So why hate? It's good to be skeptical in this industry. But hear the evidence before you judge and when you do judge, justify it with evidence and reasoning. Not just notions of ulterior motives.

• No exe or zips: This is a workaround for people who use MSIE or Outlook to open their mail. The GMail team most likely thought that the inability to send files with certain extensions was a suitable tradeoff for eliminating viral activity on their service. E.g. It's a feature, not a bug.
• No nested labels: I can't say much about this, as it is opinion.
• Whim of an external comany: This is why they provide POP facilities. It allows you to back up your email to another computer. Concerning IMAP vs POP, it would be nice if they had IMAP facilities, but it's most likely a combination of 2 factors:
  • It becomes more costly to support multiple services like that.
  • It would make the "simplicity" portion of gmail a bit too complex. Blow Joe won't want to investigate the difference... but would get rather angry if his email wasn't "around" when he wanted it to. Better to have it make a full copy the POP way, then to confuse him with IMAP.

Actually, there are a number of xUnit implementations out there. JUnit is just one of many for many languages. NUnit is by no means a rip off of JUnit than JUnit is of pyUnit, or cppUnit, etc.

For more info on xUnit testing frameworks for many different languages and platforms see (way down the page is a table):
http://www.xprogramming.com/software.htm/

Cadmann

• What is it that you absolutely need?

• What would go along with these critical feature well?

• What would be "icing on the cake?"

1. 1) Mockup something and present it to them.

1. 2) Ask "Is this what you're looking for?"

1. 3) Architect your framework (real coders should be taking part here!)

Release managers can track requirement changes and their impact (effort, schedule) on the project. These changes can be reported separately from the primary schedule, so that everyone can see the impact of scope changes.

Change is not bad. Adapting to environmental changes (competition, customer education by early prototypes, vendor roadmaps) can make the difference between a one-shot failed project and a multi-generation successful product.

Big Visible Charts is a time-tested technique for non-political status reporting that helps everyone (from senior management to QA) take responsibility for the global impact of local changes. Grab a few unused monitors and create a wall-mounted status display with 1-minute project status updates, you'll be amazed at the results.

Along with several other techniques from agile processes I have cut down my stress level by clearly communicating that I will manage to finish exactly those tasks that I finish, no more, nothing less.
Therefor I welcome external priorities for the work I'll have to do (as the tasks are also defined by our customers, this is not too much to ask for).
Baseline: For any 25 Tasks, do not accept less than 25 levels of priority. Demand that your customer/boss/whoever sets these priorities for you. After all, you will work through them in an order, and if you happen to have too many tasks for a given time, you'd better have the important ones done when time is over.

Another tip is to use strict timeboxing. It helps a lot to know that you are currently sprinting towards your goal. It does not help, if the goal moves shortly before you reach it. Accept new tasks only for the next timebox/sprint, but never allow stretching a timebox (which may be a week, a month or anything in between).

a review by Ron Jeffries with links to other books that talk about the limits of XP

Maybe the testing methodology you cite isn't so useful then, if you have to change your code when you're done testing. Backdoors are only bad if you put them in in the first place. Test First Design might be a better approach than Code an insecure backdoor as a test.

Or you can read Alistair Cockburn's proof

What it boils down to is that if I do something wrong, then at the minimum, the cost of correcting the mistake is:
cost of doing the wrong thing first + cost of changing it do the right thing - cost of doing the right thing first

As the cost of doing the wrong thing + the cost of changing it is always going to be larger than the cost of doing it right, you'll always end up with a positive number.

The rest is about momentum; the earlier the mistake was made in the cycle, the more subsequent decisions were made that are also wrong.

Note, however, this has nothing to do with the cost of adding new features later. Here, you've got nothing done wrong to start with, and the cost of changing it is equal to the cost of doing it right. What you lose is the opportunity cost, which can be iffy.

Unlike this guy, you aren't likely to survive going over a waterfall these days. A more recent discussion of the cost of change and a further examination by Alistair Cockburn might be better than reviewing Boehm again.

"The exponential cost curve is mostly in detecting and communicating the Mistake and naming the change that is to be made. XP cannot change that curve, and indeed, XP takes that increasing cost curve neatly into account. So the first lesson I get is that one should not base a defense of XP on the ABSENCE of the curve, but rather on the PRESENCE of the exponential cost curve."

Ron Jeffries wrote a good review of this book last month; his review avoids most of the flaws the comments here find in this review.

I've only read one chapter, the one up on the web, but it's quite silly. The author repeatedly describes how one team or another did some dumb stuff and it didn't work; many of these anecdotes are parodic fiction, and obviously so, but some of them are presumably real. Then he explains that that dumb stuff didn't work. The trouble is that a reader with no XP experience might be fooled into thinking that XP advocates doing that dumb stuff.

The trouble with liberals listening to Rush Limbaugh, as one poster suggested, is that Rush makes up a lot of lies and passes them off as truth. (See Al Franken's earlier book for details.) If you don't spend ten minutes investigating facts for every minute you spend listening to Rush, you're likely to come away believing a lot of nonsense. The same problem applies to this book: it's largely fiction, and the line between fiction and reality is unclear.

I've been working on an XP team for a year, and I really like it, but it certainly has its disadvantages. I'm very impressed with the people I'm working with, and I'm really happy with our product. The process we use has almost nothing in common with the processes the book criticizes. Still, sometimes it has its drawbacks, and I think you should definitely be aware of them before you jump into XP. But this book is a good source for information on the drawbacks of doing things XP prohibits, not on the drawbacks of XP. See Questioning Extreme Programming for that. (Briefly, XP requires a small team, significant buy-in and resource commitments from the customer, easy deployment, testing support, and flexible underlying technology.) And, you know, myself, I'd be a lot happier with an ATC system developed with Cleanroom than with XP.

I think it's unfortunate that XP has become so fashionable, because now we have programming fashionistas embracing and pushing it, and any technique or technology they embrace gets badly abused. Just look at Java, XML, and C++!

> because it is hard, it is not without value

Maybe it's hard because there's a better way to do it - i.e., develop requirements incrementally.

> the burden is not upon me to prove the negative

Right, but you asserted that Shlaer/Mellor provided a more "rational" approach without supplying any details of how.

> the more variable/complex a system,
> the more error prone.

Sure. But how does that relate to gathering tons o' up front requirements? And does doing big design up front help us understand a system better than if we learn and adapt as we go along?

> you seem to equate a "changing requirement"
> to a dynamic system component.

Nah, I'm with ya there. Pluggable this, dynamic that, scripted business rules, etc.

> they can never endevour to
> document/specify their process.

Ah, but XP doesn't assert that they can never specify their process - just that their process can be better specified by running code and unit tests than by a large set of [insert color here] binders. Filled with UML diagrams. Billed at $200/hour. Not that I don't like money.

> Your turn to provide the evidence

Here you go. "So XP uses a process of continuous design improvement...".

> XP will fade way, and actually quite soon

Could be! As you say, time will tell.

> the best way to deliver software effectively
> is to understand the problem domain

That's part of the process, yup. And there's a lot of other stuff, too.

> You don't need requirements before you
> start coding

What about the planning game? What about user stories? Read this for better information on XP requirements gathering.

XP has the concept of figuring out what customer want... but XP doesn't demand that you and the customer pretend that every detail of the system is in a bunch of white binders filled with stuff like "the system shall...". Instead, you and the customer work together to develop a system that meets the customer's ever-changing requirements.

> if you aren't you need more process to
> make sure you don't FUBAR things

That's the beauty of XP - it assumes that we aren't geniuses and thus we use unit tests, refactoring, pair programming to keep the code under control.

I ran across an article a couple of years ago by Chuck Allison in C/C++ Users Journal about the The Simplest Automated Unit Test Framework That Could Possibly Work. It included test frameworks written in C, C++,and Java and opened my eyes to doing best practices to the extreme. It also showed me how I could apply unit testing to my C code. You can download free Test Frameworks (Test Suites) for other languages.

Unit testing was the first XP key practice that I started to use. When I would have to make a change in my mature code, I would add a unit test section to the module I was changing (using #define TEST), and add a main() to execute the unit test (using #define TEST_MODULENAME). See examples of this on my software page. I then began using test-first programming by writing the unit test first, seeing it fail, then writing just enough code to make it pass.

Other extreme programming sites that have been useful have been extremeprogramming.org , which has a great tutorial that includes an introduction and overview, and the site Extreme Programming.

I ran across an article a couple of years ago by Chuck Allison in C/C++ Users Journal about the The Simplest Automated Unit Test Framework That Could Possibly Work. It included test frameworks written in C, C++,and Java and opened my eyes to doing best practices to the extreme. It also showed me how I could apply unit testing to my C code. You can download free Test Frameworks (Test Suites) for other languages.

Unit testing was the first XP key practice that I started to use. When I would have to make a change in my mature code, I would add a unit test section to the module I was changing (using #define TEST), and add a main() to execute the unit test (using #define TEST_MODULENAME). See examples of this on my software page. I then began using test-first programming by writing the unit test first, seeing it fail, then writing just enough code to make it pass.

Other extreme programming sites that have been useful have been extremeprogramming.org , which has a great tutorial that includes an introduction and overview, and the site Extreme Programming.

I've made best experience with this technique. Whoever asks me to do anything (usually this is a small number (~5) of different people) I ask back for the priority of the job.

If there's 50 tasks I'm pesting them for 50 different priorities, not just 3. Everybody understands that I can't do more than one thing at a time, everybody seems thankful that they can set priorities and don't rely on my priorities.

From time to time (if I believe something doesn't fit or someone misuses this power) I check back with my boss, but usually this is not necessary.

Another hint would be: Don't keep backlogs. Accept work for a month, not more. Nobody (especially not you) is happy to see that a task will be performed in a year. (and when the year is over it will be another year, because so many new tasks came up). When the month is over, get more work. Some recommended reading on this topic comes from xprogramming.com: http://www.xprogramming.com/xpmag/PetitionTheKing. htm

So, in your company, business people get to make technical decisions? Do technical people get to make business decisions, like how many weeks vacation the janitor gets?

I've got two questions for you:

Does management burn the midnight oil alongside you, or does he work a 40-hour week?

Have you tried XP?

</rant>

I'd say the big deal is your guys spent 3 man months on something they could have just downloaded. There are 4 .Net/C# frameworks on this list, and 7 on this one.

The /. article describes Bill Venner's justification for writing his own; did your guys have a reason for what they did, or was it just "not invented here" syndrome?

Another question is how you could spend as long as 3 months on this at all, xUnit isn't complicated...they've just pissed away roughly £15,000-£63,000 of your customers money (depending on if they were permies or conslutants).

If there's literally zero time for anything but unit testing -- if the customer is saying, "you must deliver perfect code in this agressive timeframe" -- then the project is doomed. (Can you put it to them that way?) Find some way to accept the job without being seen as responsible for its inevitable failure.

You can't do "big design up front." I'm sure there's no way you'll get detailed immutable requirements. You're going to need lots of unit tests and lots of automated tests. (If you're description of the other trends is accurate, it's a given the customer will change their minds during this project. You already know you'll make mistakes and have to recover from them. That means you're going to make changes to working code, and will need to ensure your changes didn't break anything.) It's also a small project.

Extreme Programming isn't a good choice for all projects, but it sounds as if it might be for this project. If you look at the twelve practices of XP, most of them seem applicable.

Some of the practices won't apply. You can't "pair program" if you're working by yourself. I don't know how close you'll be to "on-site customer." The call for acceptance testing is one you'll need to deal with no matter what process you follow. (This is not the right setting to discuss 40 hour work weeks, so let's not concentrate on that one.)

On the other hand: Small releases and the planning game will get the most important work done first (i.e., when the schedule slips, it'll be less catastrophic than it might otherwise have been). Automated unit tests can speed development, and they are (XPers hardly ever say this) useful design artifacts in their own right.

Having said that, let me say this. Some of these practices take some time and experience to master. (Personally, I can't yet say I really "get" XP-style automated unit tests. I often run into cases where I can't find "the next test" that leads me in the right direction.) You won't be able to pick up Extreme Programming Explained (Amazon.com, BN.com) today and be a good Extreme Programmer tomorrow. Using a new process, even a good one, is like using a new programming language (even a good one): you'll be slower when you're climbing the learning curve. You may not be able to afford that on this project.

Finally, if you turn the job down, do so in a way that doesn't involve burning any bridges. Perhaps say you don't think anyone could succeed under the specified terms. You may yet be called in later if (when?) the first developer hired can't make it happen.

Good luck!

I have found Extreme Programming techniques to be very useful. I do much less debugging now, because I write unit tests as (or even before!) I write the methods. I use the JUnit framework for all the Java code that I develop.

I'm sure that debugging technology can and should be improved, but I think that better development methodology reduces the need for debugging.

I find that testing "code with side-effects" (ie: database inserts) is the hardest type of code to test, and I haven't yet found a solution that satisfies me.

On the eXtreme Programming mailing list, there's been a lot of discussion about how to deal with databases - some deny the need for databases altogether, some advocate using Mock Objects for testing and even development etc.

As the XP mailing list talks about, you can always create mock objects and test their state, etc, but it's still not quite legitimate. You end up building these massive meta-models that themselves might have issues. Perhaps the best solution I found was to have a "test" instance of your database that would always contain an appropriate seed of test data. If you keep your "side-effect code" and "test the side-effect code" inside of a transaction that you roll-back, you're pretty well off. Unit tests can start taking a long time, though.

Things get worse when you look at Ron Jeffries' Adventures in C# where he starts on the slippery slope of re-implementing the textbox class as a mock object.

Not much of a point here, more of a "me, too" response.

• It seems to require some failing tests that are to be fixed before you can create a development branch. How does this mix with refactoring? Do you have to invent a test for "This piece of code should be more elegant", or what?
• Is it possible to integrate the mandatory testing with an existing testing framework like one of the xUnits? Writing a shell script for each test case seems to be stupid.
• How about IDE integration? An Emacs mode?
• In general, what if I don't like something about the process it wants to enforce? Is it flexible enough to be adapted to local policy? Is it really a good idea to couple revision management and workflow? (It surely is not the "Unix way", which it like to integrate well with)

Here's another review from the Extreme Programming camp that takes the book to task on several issues.

More information about XP can be found here or here.

• time to delivery,
• scope,
• cost, and
• sustainability (including code quality, product reliability, developer morale, etc).

Once upon a time ...

... there was a great king who desired to give a State Dinner for a few thousand of his closest friends. He called in his Chief Artisan and informed him of the dinner plans. The king described how he wanted the finest table settings, all in gold and encrusted with intricately carved jewels. The Chief Artisan did some sketches and agreed with the king on what the settings would be like. They agreed to meet again in a few weeks and look at the schedule for production of the table settings.

A few weeks went by, and the Chief Artisan came to report. He showed the king a time schedule showing creation of prototype settings, review by the king, and production of the final table settings. The schedule showed that the settings would be finished in November, but the king preferred to have the party in October, when the weather would still be fine. The Chief Artisan agreed to adjust things for completion by October before the next meeting.

On schedule, the Chief Artisan appeared with prototypes, and a revised schedule for production, showing completion by October. The Chief Artisan also recommended that they meet at regular intervals to check progress. The king reviewed the prototypes, which the Artisan had simplified because of the shorter deadline. The king requested more cherubs on the plates, more beautiful carving on the embedded jewels, and more complex scrollwork on the knives and forks. The Chief Artisan protested that these new features would jeopardize the schedule, but the king reminded him who was king and who wasn't. The Chief Artisan withdrew.

At the next project review, things were measurably behind. There were too few jewels ready, so that the plates were not complete, and there were far too few knives and forks done. The king demanded that the artisans work harder. The Chief Artisan protested, but the king again reminded him of their relative positions. The king demanded additional reviews, even more frequently than already agreed to.

At the next review, not much more was done. The king insisted on visiting the shop to see what was being done. The next day he arrived. The artisans were a bit nervous, but they knew their arts and mostly continued with their normal efforts.

"What is that man doing?" asked the king, pointing out an obvious slacker.

"He is resting his eyes and hands, O King," replied the Chief Artisan.

"An egregious and insulting waste of Our time," declaimed the king. "They should rest at night, not while working."

"It shall be as you say, O King," answered the Chief Artisan.

"And that man over there," asked the king, "what is he doing?"

"He is sharpening his tools, O King."

"Again a waste of Our time. No wonder you are accomplishing so little. Henceforth, tools are to be sharpened at night, not on the job."

"As you wish, O King," sighed the Chief Artisan. They parted until the next review.

Halfway to the next review, the Chief Artisan sent to the Chief Steward, requesting some new apprentices to help with the work, specifically with sharpening the tools. The Steward, mindful of the King's budget, solved the problem in the age-old way of Stewards, by not replying to the request.

At the next review, more work was in fact completed. The king inspected the pile of completed plates and utensils. At first he smiled in satisfaction, but as he looked more closely his smile turned to a frown. "These plates," he growled, "the cherubs are rough, not fine, as were the earlier plates. Our guests will not be suitably impressed if this is the best you can do."

"The work is rough, O King, due to the use of dull tools, as you commanded."

"We did not command you to do poor work, Artisan, We commanded you not to waste time!"

"O King," the Artisan explained, "just as Your Majesty cannot have a good party without good food and settings, my artisans cannot create good art with dull tools."

"Must We tell you everything?" screamed the king. "Have someone else sharpen the tools!"

"I have requested new apprentices for just that purpose, O King, but the Steward has not responded to my request."

The king roared, "Do not bother Us with these internal matters, Artisan. We are the king. Allow the artisans to sharpen their tools as needed: but they must make up the time by working overtime."

"It shall be as you say, O King," responded the Chief Artisan glumly.

The king returned to the inspection. Soon, he was again enraged. "These plates, many of them do not yet have their carved jewels. What is wrong here?"

"There has been increased spoilage of jewels, O King," replied the Chief.

"What is causing this," boomed the king, "Are your people so completely incompetent?"

"With all due respect, O King, jewel carving is a delicate task. Without frequent rest periods, the carvers eyes tire and their hands shake, resulting in spoiled work."

"You tiny fool," boomed the king. "you must punish the workers who spoil my precious jewels. Clearly they are not being careful enough."

"It shall be so," bowed the Chief Artisan.

At the next inspection, the king swept into the area filled with suspicion and with a visible air of challenge. When he saw that quality was improved in the carving he calmed a little, and when he saw that most of the plates had their jewels, he became almost happy. Then, however, he counted the stacks of completed work and found that while quality was up, not as much work was completed.

"What are you doing wrong now, Artisan? Must you yourself be punished?"

"O King," replied the Chief, "several of my key artisans have become ill from the punishments You ordered and cannot work. As well, a few have left the kingdom and gone to the neighboring kingdom, saying that their work will be more appreciated there. As a result, we have fewer workers and can produce less work."

"We ordered that your artisans work overtime," roared the king, "has there been no improvement from this?"

"In fact the reverse has happened, O King. Again, there have been those who have left the kingdom in search of a place where they will be more appreciated. Those who remain are mostly from the lower ranks, and while they are energetic, they lack the experience to do the work you require. And as they tire from overtime, again there has been spoilage and lost work."

"This is unacceptable! We are most disappointed in you, Artisan. Return to your quarters and await our decision as to your fate." The Chief Artisan withdrew, certain that his days were at an end.

The king was mightily concerned. The Chief Artisan had failed him, and surely must die. Yet the State Dinner was important and the settings must be completed. And, though the king hated to admit it, the Artisan had tried mightily to do as he was commanded. The king decided to consult his Wizard, who had been his mentor and sounding board since his youth.

Before he could summon a messenger, a loud explosion and a cloud of smoke announced the arrival of the Wizard. It was said that the Wizard always knew when people thought upon him.

After jumping a bit, the king wasted no time. He described the events surrounding the dinner, then stated his concern. "Wizard, it seems to me that the Chief Artisan has disobeyed me and must die. And yet, do not We bear some of the blame for the problem through Our inability to advise him properly? And in any case, without the Chief, how can Our artisans possibly prepare for the dinner?"

The Wizard reached up and plucked a pigeon from thin air. Drawing his dagger he contemplated viewing the pigeon's entrails for insight, only just in time remembering that he was in the throne room. Stuffing the pigeon into one of his capacious pockets, he instead snapped his fingers, producing a brief flash of flame followed by a plume of smoke. He observed the smoke as it dissipated, discerning patterns that only he could see. At last he turned back to the king.

"Majesty, I have long studied these problems and can offer some insights. There are four, and only four, Aspects of work which we must consider. And these I call Resources, Scope, Quality, and Time. Immutable laws of nature relate these Aspects. Let us consider them and how they are related."

The Wizard went on: "I call the work Your Majesty demands, the sum of all tasks, Scope."

"A curious name, Wizard, but I am familiar with your arcane ways. Go on," said the king.

"Consider now the Resources: the number of artisans Your Majesty has. If an artisan be lost, shall the work, or Scope, increase or decrease?"

"It depends on whether the lost artisan be good or bad, and what responsibility he has been given," answered the king.

"You are wise, O King. Yet Your artisans are quite capable, as You justly require, and surely they divide responsibilities generally wisely. That being so, what then shall be the result of reducing the Resources?"

"We still demand what We demand. And the work must be of the highest Quality. Then it must take more Time," answered the king thoughtfully.

The Wizard nodded. "Just so, O King. If Scope and Quality change not, and Resource is reduced, then Time will stretch out. Wise you are."

The Wizard continued: "Now, O King, consider what must happen if we hold the Resource constant and demand that the artisans produce the same work in less time. What will then occur?"

"They will labor harder so as to please Our Majesty?" the king asked hopefully.

"This has been Your Majesty's experience?" asked the Wizard slyly.

"No," the king admitted, "although they tried. At first it appeared to be working, but overall they got less done, and when We demanded more output, the work itself was poor. Working them harder only resulted in poor results, and some key artisans actually fled the kingdom."

"Can you put this in terms of Scope and Quality, O King?"

"Let me think, Wizard. Ah, I see it ... if Resource and Scope remain the same and Time is reduced, then Quality must inevitably be reduced."

"Yes, O King," agreed the Wizard.

"But this is unacceptable," cried the king. "The goods we receive must be of the highest Quality!"

"Then, Majesty, what can be done?" asked the Wizard.

Thinking, the king gazed out upon his kingdom. "Your questions are challenging, Wizard. But let me think, I can see through this maze of yours. Wait, I have it! You would have me realize that even I, your king, cannot dictate all four of these Aspects. If I hold Resource, Time, and Quality to myself, then Nature controls Scope. And yet if I hold Resource, Quality and Scope, then Nature must control Time. Is this your lesson?"

The Wizard replied, "You speak wisely, O King. It is as you say. Your artisans are serving you well within the limitations given. They will apply their skills to their best ability at all times, but they cannot change this law of nature."

"Can I then do nothing, can I have no idea what will be accomplished, or when?" cried the king.

"Not so, O King. In his work, Your Artisan well understands the relationship between the Aspects. If You will tell him Your wishes regarding three, he can estimate the value of the fourth. And though events may change the results in detail, he can keep You informed of progress against his estimate, in time for You to prepare for the outcome. If You work with him on the Aspects, he can progress most effectively, and You can guide him effectively to the best result."

"Well done, Wizard. You have assisted Your king, and in the doing saved the life of the Chief Artisan."

With this, the king turned to dismiss the Wizard, only to find that he was already gone. Shrugging, the king summoned the Chief Artisan.

The Chief Artisan entered the room expecting the worst, yet knowing in his heart that he and his workers had been doing their best. Trembling but erect, he awaited the king's word.

"Fear not, Artisan," the king began. "I now see what you have been trying to tell me. I rely now upon you to tell me how best to prepare for the dinner I have in mind. Be aware, however, that the invitations are out and I cannot bend on the date. Would more artisans help?"

The Chief thought briefly, then produced his answer. "We might improve by adding a small number of artisans, but this will have little effect in the time left, or may even slow us down as we teach them our methods."

The king began to glower, then remembered what he had learned. "What, then, do you recommend, Artisan. I know that you desire only to serve as best you can."

"It is so, O King. Here is my solution. We cannot much change our Resources, and the Time is given. Your Majesty must have the highest Quality, which leaves us with only Scope to vary."

"You use terms which I have only today learned, Artisan," remarked the king. "Have you been speaking with my Wizard?"

"Indeed, O King, he advises us often in how we do our tasks, which he calls Work Process. He is strange, yet his ideas have worked a powerful effect."

"Strange he is, Artisan, strange indeed. But go on, what of Scope?" said the king.

"Here is what we can do. We can produce all the place settings you need, of the highest quality, by reducing scope in any of these ways: we can return to the simpler design of plates which we showed you, removing the cherubs; we can provide simpler utensils, though still of the highest quality; or we can produce fewer plates or utensils. Among these, Your Majesty may choose."

His Majesty thought, then pronounced his decision. "We will have the appetizers during the tour of the Royal Zoo. I will have the cook produce food that can be eaten in one bite, from the fingers. This food shall be served by the loveliest maidens, who shall circulate through the guests with trays. Thus we will need fewer dishes and utensils."

"It is good, O King," said the Artisan. "Yet still the time will be tight. There remains a risk that we might not complete our task, hard though we will try." The Artisan made to leave.

"Hold, Artisan, hast thou learned nothing? We have not as yet done Our Royal Part, if there remains risk. We shall say further."

The Artisan waited.

The king continued, "Yes, We have it. You will carry out all three of your suggestions, ensuring the best possible result for the State Dinner. You will make fewer plates and utensils as We have already commanded. Those which you make, you will make simpler, yet still as high in Quality as We deserve. Can this be done?"

"Of course, O King," said the Artisan, now almost calm. "If I may suggest, we might lavish the bulk of our effort on the dinner plates, leaving the other dishes simpler, as a frame for the main course. And similarly we will keep the utensils simple, again setting off the beauty of the dinner plates."

"Yes, Artisan, this will suffice," said the King. "Is there anything else?"

"If I may, O King, two things. First, should anything go wrong, I crave permission to change the details of the designs to ensure delivery. I will of course inform Your Majesty immediately to be sure you agree."

"Good, Artisan. But more: you must call upon Us for further creative reduction of your effort if it is needed. Just as We can change the appetizers, We can change the desserts if need be."

"You are wise and powerful, O King. It shall be as you say."

"And the second thing, Artisan?"

"It is too soon to be certain, O King, but it may be that we shall exceed these goals rather than barely meet them. Should this be the case, would you prefer that we enhance the designs accordingly, or perhaps you would wish some small gifts for your guests?"

The king beamed. "Now you sound like Our true Chief Artisan, supporting Us in every way. We see now that by releasing you from undue pressure We free you to do more, not less, to please Us. But let Us not speculate now. When you find that you can do more ... wait, as the Wizard would say, when you find that Scope can be increased ... see Us then and together we will decide what to do. Perhaps we will even give your people some time off ... no, this is, after all, only the 10th century. I am ahead of myself. Workers' rights are centuries away. In any case see Us, and together we shall decide what to do."

"As you wish, O King," said the Artisan. "I am now certain that we can serve Your Majesty as You deserve." He bowed and withdrew, happy to have his head still on his shoulders, and confident that his artisans could perform as the King required.

The dinner was a great success, and the Chief Artisan even struck up a lively friendship with one of the serving wenches. As it turned out, they all lived happily ever after.

I have found that an excellent way to get project owners more involved with doing things the right way is to use Extreme Programming

1) write the tests first (i.e. define the interfaces for the code that is going to be implemented first ... this focuses you to think about design up front)

2) short iterations - keeps the project in synch with the owners expectations. If an itteration is 2 weeks (my usual cycle), then the owner is always on top of whats going on

3) continuous integration - everyone must checkin as soon as they've written the code the completes their current task (tasks should never be longer than a day or two). So, if something breaks at most you've only got a day of code to go through and find out where the bug is. And, since you're writing the tests first (i.e. JUnit or its clones http://www.xprogramming.com/software.htm)

4) Simple design. Never add code that you don't need right now, because you think it will make adding a future feature easier. Often requirements change. The best case is you guess right and you've already done the work by the time you get to that feature. However, if you're even slightly wrong about the feature, then you'll have to rework it anyways, so don't do it ... ever.

All of these play together to make the boss or project manager more involved (not what you wanted to hear), but in return you usually get more control (including testing) because the tests are actually part of the design process and have to be written before any code is.

Good Luck!

Extreme Programming (XP) is a very simple and effective discipline of software development based on values of simplicity, communication, feedback, and courage. It includes techniques for programming, and techniques for planning and working with the "customer", the individual or group that has responsibility for making business decisions about the program that is to be written.

Read more about XP at extremeprogramming.org, or on my site, XProgramming.com.

"This book should appeal to XPers and non-XPers alike who recognize that automated testing and continuous integration are good things for any project." ... ... "The book is a good introduction for the uninitiated and a valuable reference for those plying their trade with these tools. Don't miss an opportunity to easily automate your Java project and spend more time delivering business value!"

--Mike Clark

Check out the full review athttp://www.xprogramming.com/xpmag/books200 20203.htm

http://www1.fatbrain.com/asp/bookinfo/bookinfo.as p?theisbn=0932633439&vm=

http://www.xprogramming.com/xpmag/c3space.htm

Re-reading my post, I guess it came across that I think XP, per se, is bad.

On the contrary, I feel that many of the assertions XP makes are quite good software engineering practices. However, I also feel that many professed adherents of XP become fascinated with the methodology and forget that, in the end, software engineering is about building a product that makes the customer (not the fake customer on your XP team, the real customer holding the checkbook) happy. This means that XP methodologies must be applied with careful judgement and an eye towards flexibility -- the most elegantly organized project in the world will still net you zero income if it doesn't get out the door on time with all of the required features.

That said . . .

> I've found that it makes a lot more sense to
> focus on testing the hard stuff, like this,
> than simple things like the ones you mentioned.

Exactly my point.
However, I think very few proponents of XP actually understand the principle outlined in this article, namely that XP is a set of best practices and NOT a color-by-numbers guide to successful software engineering. There's a great deal of XP fundamentalism out there, mostly on the part of development managers who are excited to the point of bursting by the childishly simple ABCs of XP according to [insert snide columnist here].

> By the way, it's also quite useful (totally
> apart from XP) to decompose such a beast into
> pieces you can test effectively.

Unfortunately, the actual code that inspired my description is about as atomic as you can get in an asynchronous system. A few inputs, a few outputs, and a very well-defined domain of functionality. However, both internal state and external state, as well as the timing of incoming messages, are quite complex, and non-trivial to simulate as part of a unit test.

My point being: unit testing is Hard in many situations, and most XP literature I've read glosses over that fact and downplays the necessity of picking the right things to unit test.

> Can you point to any project which did XP (most
> or all of it, not just talked about it) and
> resulted in an unhappy customer for that reason?

Well, I can't point to any project that managed to successfully implement "pure" XP, the kind that I've only seen in a training center. Most of the ones I know of that tried it gave up on it pretty quickly, usually because either:
1) They didn't have enough staffing to constantly pair program AND get all the necessary features completed
2) Their time frame wasn't sufficiently flexible to allow for the additional time incurred by XP-style unit testing (as opposed to a more traditional test suite).
3) Their Real Customer (not the XP customer) was not a nice and reasonable person with an understanding of how software development ought to work. He kept demanding additional features, some of which were negotiated away; the remainder necessitated that process be streamlined in order to deliver them on time.

While only a couple of these projects failed, they all wasted effort and money on implementing a methodology of which they had little understanding, but were led to believe was Just That Simple.

Nobody can sensibly argue that the generalities espoused by XP are bad. Testing is good. Iterative development is good. Refactoring is good. Pair programming *can* be good, in the right situations. However, the manner in which XP's principles are presented and disseminated (i.e. "the cult of XP") is, for the most part, misleading. Like most cults, The Cult of XP claims to have the one right and true solution to every problem in existence, which can be yours if you just do A, B, and C. Like many cults, The Cult of XP has some good things to say; in fact, it DOES benefit you to join up if your problem fits certain constraints. Also, unfortunately, like many cults, the Cult of XP is more interested in casting aspersions on its detractors (who are "afraid of change" or "unenlightened") than it is in engaging in serious examination of situations in which its dogma doesn't exactly hold true.

I'm with Kent Beck on this one:

When partnering with Kent Beck, most everyone has this experience:

Something goes wrong. The code doesn't work. You start to think: "What could cause that to happen?" Kent doesn't think about what the problem is. He just sets a halt in the system and lets Smalltalk tell him what the problem is.

Sometimes you're right about what the problem is. If you're really quick you'll be able to tell Kent what to edit in the window he's already looking at. If you're really quick.

Sometimes you're not right about what the problem is. Forget it, he has already fixed it.

Train yourself to think about where to put the halt, not to think about what the problem is. Of course it's a great feeling when you can reason to the problem. But we're not here to make our brains feel good, we're here to get the code working as quickly as possible. Setting the halt and letting Smalltalk tell you will help you build working code faster.

I develop Java using IBM's VisualAge for Java. Here's what I do when I find a bug:

I don't try to work out precisely where the bug is. I just set a breakpoint in its general vicinity.

I step through until I find what's going wrong. I make liberal use of my ability to inspect any variable in scope, to highlight pieces of code and evaluate them while the program is halted, or to write random code snippets in the evaluation area, and inspect their results as they execute in the context of the halted program. The big problem with writing printfs is you have to guess (out of everything that's in scope, and every method you're calling) which ones are giving you bogus results. If you knew what the problem is, you wouldn't need the printfs. If you're wrong, you have to write a new batch of printfs and run the whole test again. If you're in the debugger, you can just go through them one by one, from most to least likely.

When I locate the bad code, I fix it from the debugger, save (which drops the stack frame back to the beginning of the method), and let it run. The test then goes green.

I guarantee, using this method, 90% of the time I'll have fixed the bug while you're still writing printfs and scratching your head.

Try looking into "Extreme Programming" concepts.

www.extremeprogramming.org
www.xprogramming.com

Your philosophy of coding emphasises (or seems to me to emphasise) many of the same things recently elaborated by the new "fad", Extreme Programming. What's your opinion on this rediscovery? How strong is the correspondance?

How, if at all, does Forth help you to do things like refactoring and unit testing in ways that other languages don't?

-Billy

A good piece to use in your overall solution is the xUnit testing framework from http://www.xprogramming.com/software.htm

So, you're saying that in an instance where you are unsure of who your customer is, or what they want, then XP doesn't make sense, and traditional methodologies are more effective?

One of the requirements of XP is that the customer is on-site, so if you don't even know who the customer is you can't do XP. If you don't even know who your customer is no methodology will be effective.

What about instances where what the customer wants changes over time (new business strategy; new tactical goals; change in company emphasis) - how well does XP deal with those cases?

That's one of the main points of XP. What the customer wants always changes over time. XP deals with that by working in short (three-week) iterations instead of trying to figure the whole thing out up front. Every iteration the customer can completely change their mind about what they want.

Please check out XProgramming.com and ExtremeProgramming.org. You'll get a much better idea of what it's about from those sites than you will from me or from a short article.

One of the things people should bear in mind is where XP was invented - Smalltalk (and VisualWorks, part of Cincom Smalltalk, in particular). It still works best in Smalltalk. Why?

Immediate feedback. You can create the tests initially without having the actual code written yet (as the tenets call for) - Smalltalk allows for that

You can test early and often. Why? because Smalltalk allows for testing of partially written systems, something statically typed systems generally can't do. And before you say 'VisualAge Java', recall that IBM are busy re-doing that in Java - and removing the dynamic features as a result

If you want to try it out, try Cincom Smalltalk:

Cincom Smalltalk Home Page

Cincom Smalltalk Download Page

to download it. You should also know that the people who invented XP (Kent Beck, Ron Jeffries, et. al.) did so in VisualWorks. It was born there - it's best there.

If you want to see the Original XP project and how it came about, follow this link. It's got tons of information on the beginnings of XP - and points out the Smalltalk origins. So if you want to do XP with the best results, do it with the best tools.

XP is a software development methodology. Check out XProgramming.com or ExtremeProgramming.org for more information.
j

"It's not whether or not you're paranoid. It's whether or not you're paranoid enough."

XP is an interesting (and controversial) methodology that has proven its usefulness in real projects, and it is nice to see it covered on slashdot. It is gaining acceptance in the software industry. One indication of this is the number of talks on XP at the SD2001 West conference in San Jose 8-12 April.

However, decent references are sorely missing from this story, like for example
the book by Kent Beck and one of the more comprehensive web sites, www.xprogramming.com by Ron Jeffries, with links to a lot of other resources on XP.

I work at a large telecommunications company and I work on a very large (understatement) database with billions of records loaded daily. We employ the eXtreme Programming model for development. Our database is a release database and we modify it weekly. Adding new features, tables. Changing things as we go. As long as we control the interface changes are 'cheap' in cost. I shudder to think of how all these changes would be under an OO database. If you plan on using an OO database, you are basically cut out of the xprogramming style. You spend MUCH more time in 'designing' and less time 'delivering'. Thanks, but no thanks.

Since my team and I switched over to Extreme programming we've generally not needed to do any overtime.

We all work roughly 8 hours per day, and are very productive. I think this is due to many factors, but mainly pair programming, and the "8 hour burn". You make fewer mistakes if you're not terminally tired.

Just my two cents.

Grant/Kablooie!!

...a CNet article which points to...

...the home page for "Extreme Programming" which promotes...

...the book "Extreme Programming Explained" about the subject which is...

...a followup to "Planning Extreme Programming" which was...

...reviewed on Slashdot just five stories ago.

This kind of reckless ignorance of Slashdot's own archives is bordering on obscene.

Debuggers: Check out visual age, it is meant to be excellent. However, having used both VC and JBuilder, I don't find any limitations in the java debugger. Why? Because I spend much less time using it. In fact I rarely need it at all.

I live In the VisualAge debugger. The ability to edit the source, hit save, have the changes linked into the running application, and immediately step over the code I just wrote to make sure it does what I want it to is pretty damn good. If you're unsure of exactly what to do with a method (say you're working with some unfamiliar API or toolkit), you can just leave it empty, set a breakpoint, and then be able to inspect all the objects available to you while you write the method in the debugger's source pane.

Just set the halt contains some very, very good advice for working in this kind of environment. (Okay, it's about SmallTalk, but VAJava is really VASmalltalk with another language kludged onto it)

Charles Miller
--