Slashdot Mirror

XP does not suggest coding without considering design.

You obviously don't know anything about XP. Take a look.

"methodology" -- I suggest "method"
"empowers" -- "lets"
"life cycle" -- ???
"groupware" -- ???

"XP is successful because it stresses customer satisfaction"

"XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle"

"Managers, customers, and developers are all part of a team"

Looks like I need to bring Joel Spolsky's excellent article, Things You Should Never Do, Part I, to a new readership.

The article speaks for itself, but essentially Joel's point is, "If it ain't broke, it's going to take you a heck of a lot longer to rewrite something inferior than you could've ever expected." Old code has tons of lessons learned that you'll never tease out. New code is easy to read and can implement every buzz word you'll find on O'Reilly Net right now, but it won't be battle-tested.

If you're still able to even think about throwing out your old investment and moving to CGI and BSD, however, I'm thinking your site isn't doing much very fancy. If you don't have much customization invested in your propriatary system, what Joel and I are saying is moot, especially at the licensing fees you're mentioning.

I'd also point out the title is very misleading. It's not Java that's the issue -- it's your system's architecture. Java is just as capable as creating a, "largely static site that is generated (written out to cache) from a new, simpler content management system," as language X. This is quite similar to the discussion we had about whether Java is an SUV just a while back (if it is an SUV, btw, that's not a bad thing). Your programmers' skillset is what's most important. If they already have a familiarity with Java, why ditch it?

So, keeping true to the post that says the recommendations here come out our arse, here's another pulled from the same place:

I'd recommend trying to refactor your current codebase to do two things. First, try to implement your static page idea using your current system. Two, take out as much of the crappy, non-scalable system that happens to be written in Java as possible. You don't name the system, but the whole advantage of Java is that it doesn't need to be platform-specific (if done right). Ditch Solaris. Create a server-farm of cheap x86 hardware with Linux or BSD with a JVM installed. Reread your license -- if you have thirty "clients" (new Linux servers) making static pages from one legacy server's dynamic content, can you pay a lower fee?

PS -- Who said Java was good for prototyping? Visual Basic (and vbscript/ASP or *gulp* ColdFusion), sure. REALbasic, sure. Java? Are you folks mad?!! ;^)

Heh... team programming where you take turns commuting to each others houses for a day. I think that sounds kind of fun. Even more fun when the entire office comes to your house one day a week...

Markup languages are hardly extreme, but surely they could push the bounds of the latest standards and do something truely extreme. ;-)

Mike

The article mentions how the developers worked "... arduous 12-hour programming shifts." This goes against one of XPs core practices: No Overtime. However, if a team is well-motivated (as these guys were), I think it becomes possible to stretch this rule. The second that their motivation wanes, they should switch back to a regular schedule.

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.

Maybe they were following the XP-methodology and were pair programming?

Maybe they were following the XP-methodology and were pair programming?

.. the comment I referred to, earlier...,
but the example you showed me might well be "optimized" rather than calculated, eh?

-shrug-
I'd been thinking of defects, flaws, and other things that give Excel it's Look & Feel[tm], though, like the other comment ( wherever it is, I'm not going digging again ) .. about a query that took over 20 minutes on Excel, but a minute or so on Linux: oughtn't they too be duplicated, even if one has to set an option for 'em ( like Stupidly-Bad Slowness Option, and Compromising Data-Integrity Option )?...
hmmm..
I seem to remember another discussion, here on /., where someone had a problem with Excel: they personally had switched to Linux/OSS, on their desktop, and they did a spreadsheet in their system, and their boss had a different result, so they went over every last thing, and discovered that the Excel version was rong...

I don't use Excel, so I'm stuck with the choice of gnumeric ( SuSE 8.2 pro installed the "stable" version, and it was obnoxious enough in interface & habits that I didn't like it -- now that I know-about the "development" version being good-enough for beta, by gnome's coding-standards, I'm downloading it to try compiling/running it ), KSpread, and OO.o's spreadsheet ( I don't much care for OO.o, as it's a resource-hog, and takes a very long time to start on my 5-year old machine, even with 320MB/K6-2 )... KSpread seems a tad unfinished, so I simply chose to work on stuff not needing spreadsheets for a few months...

Now I need one, and gnumeric 1.1.x awaits, so I'll dig into it ta see if I dig it, see..

I find the reports about bugs in Excel's accuracy to be probable, though, because MS cannot possibly code by test-first ( and end-up with the results they do ) XP-style, and almost all of the Excel users don't check the results with a different spreadsheet to see if the results are correct ( who backups their system? who checks their tools' integrity? who verifies anything ), and since it isn't OSS, bugs are more likely to remain long-term ( the stunning amount of serious, been-there-for-years vulnerabilities in windoze... )

Knowing gnome's coding-integrity standards ( not necessarily caring for the gtk interface, though: QT's much nicer to work-with ), knowing OSS's more effective in destroying & eradicating bugs, I'm not going to trust my future to MS-Excel, when gnumeric is an option. Period.

( thanks and generally-emanated hugs, for all gnumeric & gnome developers, eh? we gain vastly from this all, and appreciate it, though sometimes our griping-habit overrules wisdom & wellbeing )

XP was built on the knowledge you just mentioned: That the Q&D solution is necessary, and that if you try to follow set procedure (or the "waterfall model" as it's called) where you have a requirements, design phase, implementaion phase, testing phase you will most likely fail.

Basically, what XP is all about, is to acknowledge that the specification is useless, beacuse after a couple of years when the project is finished, the end result doesn't look anything like the sepcification anyway. At least if you want to survive in a dynamic market. We have all seem that in the real world, the requirements change during development, and if they do, you need to go back and change the spec, and then possibly reimplement large parts of the code.

So, how do you go about solving this? Well, first of all you have to understand and believe in a couple of mantras:

• The implementation is the specification
• Refactor mercilessly
• Do the least thing that could possibly work
• Test driven development

Here is the list of development rules.

The implementation is the specification

This means that instead of writing a specification before programming begins, you let the application evolve (very similar to most Open Source projects actually) and if the requirements change during development, you change the code to adopt.

Refactor mercilessly

This is absolutely nessecary in order for the previous point to work. What it means is that you should not be afraid to change the layout of working code, to make it easier to add new features. With good refactoring you don't need a complex design in the beginning, which means that you get to market more quickly.

I strongly recommend you read Martin Fowlers book Refactoring, it's a real eye-opener.

This leads us up to the next point:

Do the least thing that could possibly work

If you are thinking of implementing a couple of abstract base classes and interfaces to make your object design super generic, so that it can be used for a lot of differnt things in the future. For example implementing a plugin architecture in your file parser or somehting like that, you need to ask yourself the following questions:

Am I going to need this abstraction now? and If I need it in the future, will it be easy to refactor the code so it gets that functionality? If your ansers to there questions are "no" and "yes" respectively (which they usually are) then you should not do it.

Essentially: don't do anything until you need it.

Test driven development

All this refactoring, and no solid specs can be a bit scary, especially in the beginning. A common question that pops up is: "how can we guarantee that the code works if you keep changing it all the time?". The answer is: unit testing. The rule of thumb here is: Implement the test first, then you implement the code so that the rest runs. Whenever you are going to fix a bug, write a unit test that triggers the bug first, and then fix the code so that the test succeeds. You then make sure you run the ever growing test suite several times per day. It helps a lot in catching regression bugs.

For Java, I recommend JUnit.

Now, the biggest problem you face is selling XP to your PHB's. They will more than likely feel that they are losing control, and they will be afraid that their nice Microsoft Project documents will become useless (no one seems to remember that (almost) every single waterfall project will overrun both budget and time constraints). However, there is

XP was built on the knowledge you just mentioned: That the Q&D solution is necessary, and that if you try to follow set procedure (or the "waterfall model" as it's called) where you have a requirements, design phase, implementaion phase, testing phase you will most likely fail.

Basically, what XP is all about, is to acknowledge that the specification is useless, beacuse after a couple of years when the project is finished, the end result doesn't look anything like the sepcification anyway. At least if you want to survive in a dynamic market. We have all seem that in the real world, the requirements change during development, and if they do, you need to go back and change the spec, and then possibly reimplement large parts of the code.

So, how do you go about solving this? Well, first of all you have to understand and believe in a couple of mantras:

• The implementation is the specification
• Refactor mercilessly
• Do the least thing that could possibly work
• Test driven development

Here is the list of development rules.

The implementation is the specification

This means that instead of writing a specification before programming begins, you let the application evolve (very similar to most Open Source projects actually) and if the requirements change during development, you change the code to adopt.

Refactor mercilessly

This is absolutely nessecary in order for the previous point to work. What it means is that you should not be afraid to change the layout of working code, to make it easier to add new features. With good refactoring you don't need a complex design in the beginning, which means that you get to market more quickly.

I strongly recommend you read Martin Fowlers book Refactoring, it's a real eye-opener.

This leads us up to the next point:

Do the least thing that could possibly work

If you are thinking of implementing a couple of abstract base classes and interfaces to make your object design super generic, so that it can be used for a lot of differnt things in the future. For example implementing a plugin architecture in your file parser or somehting like that, you need to ask yourself the following questions:

Am I going to need this abstraction now? and If I need it in the future, will it be easy to refactor the code so it gets that functionality? If your ansers to there questions are "no" and "yes" respectively (which they usually are) then you should not do it.

Essentially: don't do anything until you need it.

Test driven development

All this refactoring, and no solid specs can be a bit scary, especially in the beginning. A common question that pops up is: "how can we guarantee that the code works if you keep changing it all the time?". The answer is: unit testing. The rule of thumb here is: Implement the test first, then you implement the code so that the rest runs. Whenever you are going to fix a bug, write a unit test that triggers the bug first, and then fix the code so that the test succeeds. You then make sure you run the ever growing test suite several times per day. It helps a lot in catching regression bugs.

For Java, I recommend JUnit.

Now, the biggest problem you face is selling XP to your PHB's. They will more than likely feel that they are losing control, and they will be afraid that their nice Microsoft Project documents will become useless (no one seems to remember that (almost) every single waterfall project will overrun both budget and time constraints). However, there is

2. Testing, testing, and testing -- by the developers.

probably not a good idea. while I would get them to test their archictecture, algorythms and performance I would leave any real testting to a QA team (hey thats if you really have one).

3. QA, QA and QA -- by someone other than the developers!

very true. *monkey-testing* for input screens, navigation and design. Load and stress-testing may reduce any performance bugs. But the one that may bite is the RDBMS for database intensive sites where developers have made changes to stored procecures on the db. Is the SQL code in CVS? Can we roll back the db on the live site if needed? Opps we make changes to the live DB :( This is one are where having *restrictive* per-seat db licences bite.

4. Managers must know the test/ QA process should never by bypassed -- this unfortunately is probably the hardest point. :-(

the phb problem. no amount of testing, development rigour will avoid the *monday morning* crash with 100's hasty ill-defined of cvs commits in the weeks previous *mandatated* with/without poorly defined specifications. Of course you have to balance this with a business being able to adapt quickly. But I remember one marketing clown thinking *development was easy* and could be learnt in 15 minutes.

There are no *silver bullets*.

Working with fragile web based systems almost warrants XP unit type testing approach. Other agile development approachs might be useful.

If this ever catches on, we can say good bye to team work

Wow...it took them this long to realise that it costs more to do things 2, 3, or 4 times then if they had done it right the first time..."



Well, try calculate the cost of writing PERFECT PROGRAMS that has NO BUGS, and all the features are implemented PERFECTLY.


I know about the planning process, I know about programming methodologies such as Extreme Programming but in this real world that we live in, believe it or not, NOTHING IS PERFECT and software patches become the second best thing one can have.

Sorry for posting w/o reading all the replies yet. I don't think this has been covered.

I think Extreme Programming was intended in part to address this.

Can't say as I've actually been in an environment that tried it/used it.

Short of that, I would try to get your team involved with more technical workshops, conferences, courses, etc. Staying on top of the research is important, too.

Of course, both of those things seem to be highly budget sensitive, but if you are already going on work-weekends to do ropes courses or something like that, maybe sending everyone to a big conference in your industry would be a good alternative.

Clearly, you don't understand much about refactoring, then. Refactoring is a formal, verifyable process for making equivalent changes in code. Things like "extract method", or "push up".

These are tricky to get right by hand, but, since they can be done in a provably correct way, automatically, they are precisly the sort of thing your IDE should do for you.

Please read up on refactoring at http://www.refactoring.com/
and http://www.extremeprogramming.org/rules/refactor.h tml.

XP ( Extreme Programming) encourages "Refactor Mercilessly" which is what you suggest.

I highly recommend you read about either Extreme Programming or Agile Software. Both of these schools of thought have come to the realization that you never want a big design up front. Keep your design as absolutely simple, dumb, and difficult to screw up as possible. Yes, those all go together. It's the ONLY way to design stable, quality software. No object-database wrapping engines, no XML Soap Servers, massive new framework. If you can possibly get by with some PHP scripts accessing a MySQL database in a weeks worth of time to get 50% the functionality, do it!

Let me say this again: If there is any way to make it simpler, do it. Stop whining, just make it simple.

Refactor your code later, only when needed. By keeping your design simple, you'll save time and those defects you were worring about will be minimal. Testing should be done either through unit tests or simple procedures.

And here's the most important part: give them WEEKLY releases. Never "postpone" a release. This lets them know where you are at in the project, and there will be no surprised or misleading estimates or anything. Never give estimates further out than a week, and always break down tasts into smaller tasks that will take less than a week.

And stop your bitching about not having enough time for a "top bottom" design. Top bottom designs are categorical failures.

The inadequacies of debugging (not just the dubuggers themselves) as a method of ensuring quality is why methodologies like agile programming and extreme programming are garnering so much interest from developers. It's also why there has been an explosion of tools that can help with the creation of good software with fewer bugs, easier maintenance and a better chance of actually solving user problems. In the Java world, there is junit, mockobjects and log4J , that can all be used with ant so that tests can be automatically run with every build and source control systems can be automatically updated. One approach is the Naked Objects framework, which is a combinination of a design methodology and tools in one package that has advantages like the easy rapid prototyping and automatic user story docuemtation.

For example if you were using the Naked Objects framework to create a system, you might take the following approach (simplified here for posting):

1. Start with an Exploration phase, which includes:
   1. Meeting of developers, administrators and end users to discuss the nature of the problem and brainstorm possible ways to implement the solution.
   2. Create a rough prototype immediately (Frameworks like Naked Objects makes rapid prototyping like this easy).
   3. Go back to the meeting, have everybody play with the code and make more suggestions and changes. Demonstrate the prototype frequently to elicit feedback.
   4. Repeat (often) till people are mostly happy with the results.
   5. This prevents the all-to-common situation where a written specification results in excellent software that doesn't actually solve any of the problems that the users have.
2. Specification Phase:
   1. Use what you've learned to write a specification that includes lots of special case scenarios (use-cases, user stories etc.)
3. Delivery Phase:
   1. Throw out all of the code you've already written... maybe keep the class and method names, but no actual functional code
   2. Write the tests FIRST. This includes unit tests, acceptance tests and corresponding documentation.
   3. Write the code to implement various user stories and test frequently.
   4. Auto-generate user training manual, which is based on the acceptance test code.
   5. Deploy to beta testers and be amazed at how happy they are with the product and how few bugs there are.

4. Notice that approaches like this emphasize getting the design right and doing constant testing to ensure that the code that is delivered actually does the job that is expected of it. Debugging is rarely required when such methodologies are used, though profiling can be of some use.

Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).

Does it always work, for everyone, in every project? That's an open question.

Pair programming is not the first XP practice a project should try. Could a project get a lot of value out of XP without doing pair programming? I think yes, and I'm an advocate of programming in pairs; the question is open to debate.

Is the degree of customer involvement that they expect.... How many clients are willing to assign an employee to work with/at the software/website vendor full-time?

I've always found the whole "buddy programming" concept (part of XP), where one person watches the other code and points out errors, to be incredibly annoying.... you're wasting a good programmer having them sit there and call things out

Is the degree of customer involvement that they expect.

To quote their site:
"One of the few requirements of extreme programming (XP) is to have the customer ... be a part of [the development team]. All phases of an XP project require communication with the customer, preferably face to face, on site. It's best to simply assign one or more customers to the development team."

WTF? How many clients are willing to assign an employee to work with/at the software/website vendor full-time? None, in my experience.

Unless you're dealing with an utterly massive project for a heavily-staffed client, their IT guy leading this effort has more responsibilities than this one project.

I learned a couple of useful rules of thumb regarding SW project planning. One was told to me by a documentation person who worked for Bolt, Baranek and Newman (sp?) when they were designing the first Arpanet: "Take the estimates from the engineering group, double it and convert to the next higher units." - e.g., if the estimate is five weeks, make it 10 months.

The other is similar, IIRC from a UCLA project: "double it and add six months"

Everyone already knows the "90% rule of software" - the first 90% of the work takes the first 90% of the time; the last 10% of the work takes the second 90% of the time." I would add that the last 1% of the work will take the third 90% of the time. This is very, very true.

Many Open Source projects either demonstrate this or never get the 2nd and 3rd parts done - because these are the parts where the errors in the UI definition are found and fixed, often requiring complete rewrites; and the final tweaking is even harder. Like any art, the closer to perfection you want to get, the more work it is to get there. It takes just as much (or more) time to polish the last eensy bit of shine as it did to rough out the piece.

I have found the following:
1. Larger projects are easier to get right, for two reasons.
a) they must be broken down to smaller units and thus are usually more completely defined.
b) If you're reasonably good at such things, the uncertainty of the estimate on each unit is about even, so while some units go over, others go under. In a large project this can be a wash.
2. In practice, using good large-team software engineering methods, about 1/2 of the total effort expended is in the initial design - which is also where some 80% of the bugs are created and must be found. Only about 10-15% of the effort is in coding, and perhaps 30% in SW QA, which must start in the design phase.

These factors are ignored at your peril. Many programmers are used to conceiving something and cranking out a working rendition overnight. However, turning that piece of basically-running code into something that will robustly handle all possible idiot inputs and attempts at cracking will require triple that time at least.

3. In general, if you can break problems down to a tree of trivial projects, you can thumbnail the estimates for each of those fairly easily. If a piece involves work you're not familiar with, you can ask others who are familiar with that piece and plug it in or further break it down. Units of one to 3 days are about right (or 4-24 hrs.)

4. Making it smooth and glossy so that people actually want to use it will require much more. The original piece of code can only be described as a 'proof of concept'. This is like the difference between a Ford Model T (with hand spark advance) and a recent automobile. There's a lot of engineering between those.

5. Look into "Extreme Programming" - this appears to be a very good way to manage projects the way they really work, though I haven't actually run a project this way.

Having said all this, I've been pretty successful in projects up to about 10 people with myself and about 1.5 additional staff spending a total of (in one example) about a month breaking down a client-server system based on a well-understood set of algorithms to a very detailed project tree, with nodes that amounted to a few person-days a piece. This worked out to a project estimate of six person years. Of course, management screamed, but we got sign-off, and while many things changed due to company problems the parts we were allowed to build according to plan worked out very close to the original estimate. In fact, the parts they tried to short-circuit and ship early were finally fixed in about the original timeframe, with much customer unhappiness in the meantime.

I left the company shortly after.

Test first.

Thank you.

This is an actual explanation of the rules and practices of XP, not just a page full of buzzwords. It seems to center around extensive testing and customer feedback.

--grendel drago

This page explains what XP is, yet after reading it, I'm more confused...
They must have written this using the eXtreme Writing technique.

Try this link for a well laid-out explanation of what XP is and how it {does | doesn't} work.

I've never heard of it either. Google found this for me. You might be interested in going straight to the What is Extreme Programming page. Based on my quick look through their pages, it seems like just another buzz word for something that isn't really exciting (ooooh, listening to customers and testing throughout the development cycle!? How revolutionary!)

I've never heard of it either. Google found this for me. You might be interested in going straight to the What is Extreme Programming page. Based on my quick look through their pages, it seems like just another buzz word for something that isn't really exciting (ooooh, listening to customers and testing throughout the development cycle!? How revolutionary!)

It's also missing an architecture step
And it's missing testing

Both wrong.
Look at The Rules and Practices of Extreme Programming
Architecture/Planning and Testing are TWO of the FOUR main topics.

Pair programming [amazon.com] is not Extreme Programming [amazon.com]. Perhaps XP cannot be done without pair programming (or perhaps it can); certainly pair programming can be done without XP. Some people have been doing it for decades. (I have, too, in a non-XP context.)

Just because Amazon sells two books with different titles does not mean that they are not about the same thing. Pair programming is one of the RULES of extreme programming, but in my opinion it is the only thing that makes it distinct from any discussion of an ideal customer to production cycle.

Perhaps this will help: The Rules and Practices of Extreme Programming

Except for the Pair Programming I don't see these as anything other than a verbose idealistic approach to the customer --> product cycle everyone knows well.

Perhaps this will help: The Rules and Practices of Extreme Programming

Except for the Pair Programming I don't see these as anything other than a verbose idealistic approach to the customer --> product cycle everyone knows well.

Check this out.

There must be a balance of power between those who order the work and those who do it.

The best balance of power setup I've seen is part of Extreme Programming. In XP, the suits can ask for whatever they want, and they can change their mind every week. The developers get the final say on estimates, and the suits can only order as much work for the next week as was done last week. The developers deliver a new version every week, so everybody can see exactly how the project is going.

This sounds too simple, but it works really well. Every week, the businessfolk are forced to balance their desires with the reality of the development situation. With only a week between data points, nothing can get too far out of whack.

Of course, some bosses are just unwilling to face the fact that for X dollars, they can only get Y features; they will refuse to implement any system that makes that clear. But most people just want to get good software, so they will come around if you put it to them properly.

Write your own. You really should anyway.

You really sound like you THINK your problem centers around testing when it really is more of a teamwork issue that is revealing a testing deficiency now that your projects are getting larger.

For example, your statement: Now, while we enjoy programming, we're pretty lazy when it comes to testing.

Ouch, bro. Testing IS part of programming. If you'd already incorporated testing into your process, building unit tests for planned iterations of code, then you would A) perceive the tests to be indispensable in your code design phase, and B), you'd see that you've already, almost assuredly (unless your development tasks are pretty near trivial) created far more work for yourself over time by being lazy about testing. The fact is, it's really pretty hard to work on large projects on larger teams while ignoring unit tests, no matter what team paradigm you're using.

But a better team paradigm might actually be your ticket. You may want to check out XP which makes testing, test frameworks, refactoring, and other team coding techniques integral to the overall process. But whatever you decide, the result of adopting any good team paradigm that solidly implements a flexible, necessary testing process is, in the long run, vastly increased efficiency, better code reuse, and less dependence on specific individuals.

Now that your code base is getting larger it sounds like what you're really seeking in testing solutions is a better overall team plan. And after all, if you really like the coding phase, well, the unit tests need to be coded as well. That's really what a Tools Developer does, anyway.

Peace.

tooTired writes: Are there ways of communicating to management that long hours to rush a project to completion is not the way to complete a successful project?

Nope. From the information you've provided, your managers are in full-blown panic. They won't listen to reason. Time for you to fly.

On the outside chance that you've overstated things a bit, putting out an extra effort from time-to-time doesn't hurt code quality, and there are times when an extended hacking session can be useful. Sometimes you know what the code needs to do, and it's just a matter of writing it down as quickly as you can. No disrupting context switches. Just put the pedal to the metal.

But you can burn out quickly doing that. It's not advised for prolonged periods.

40-hour work weeks with the occasional super-human effort is a hallmark of Extreme Programming (XP). Check it out. (and see http://extremeprogramming.org/rules/overtime.html) Maybe your managers are panicing because you're not providing enough feedback that you know what you're doing and that you can provide results on a predictable basis. If so, you might be able to negotiate something a bit more reasonable with them.

Perhaps the book "Death March -- The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects" (by Edward Yourdon) is more appropriate. See esp. "The 'Marine Corps' Mentality: Real Programmers Don't Need Sleep!".

And good luck. Sounds like you'll need it.

See also
And their main website
For other good XP programming practices.

See also
And their main website
For other good XP programming practices.

One of the principles of Extreme Programming is that of No Overtime. You should be able to find a lot of XP resources that attest to that fact.

RUP, IMHO comes short when it comes to developing software that is really valuable to end customer. Check out the demo here. RUP wants to divide the whole s/w development process into stages and proceed in a systematic fashion where progression into one stage completely disqualifies the previous stages. The problem is that most of the times the customer never really understands what is possible and what really is required to address a business and/or process need. Which really translates to improper requirements. This is also the cause of user dissatisfaction because by the time s/w arrives the business needs/environment may have changed or shows symptoms of the same. This is very disconcerting to the end customer for his time and expenditure.

This is why Extreme Programming is a bit more applicable to what we know about s/w development, how much can we communicate to the end user, how can we make it easier for developers to let users participate in all stages of development.

That said, I actually like UML a lot. The use cases work in larger contexts while class diagrams work in narrow contexts i.e. 2-4 people can really understand what you are trying to communicate. The sequence diagrams are priceless, because even managers can follow some of it. I like to combine class diagrams with a design pattern [GoF] applications.

Rational now has an extreme programming plug-in. That very statement makes me run in the opposite direction. XP is often compared to Open Source, where users really know what they want and the whole process is more conversational rather than a contract that's been handed off to a developer.

It's actually a question of how to manage

• circumstancial-process

• civilized human-nature

Something I realized awhile ago, is that exclusion-group can't work ( for governing ), simply because its foundation is obliteration of diversity, or obliteration of choice, or obliteration-of-potential, and its self-interest becomes our world-direction Guide ( http://www.extremeprogramming.org/lessons.html for part of what seems to be maximally-valid alternative awareness and process ).

However, if the exclusive-group-power is replaced with an inclusive scheme ( I mean scheme as in a software-system, not as in multi-level-marketing ), sort-of a bath-tub curve ( exclude only the harmful extremes, include as much of everything as reasonably possible ), and the stake-holders get to vote on the issues ( rather than having powerful/influential someones decide for us ), and abusers get "modded down" in-their-influence ( notice that: abusers, rather than differers ), that can work.

It's simply a different cognitive-system: instead of personal glory+privilege+predation ( and ignore the damage done to many ), or the leftist alternative group-belonging+group-authority+no-individual-resp onsibility ( and ignore the damage done to individual ) [ I hold that political motivation is, itself, fundamentally wrong-minded. . . mind you, I'm buddhist and am working on eradicating ignorance/ignosis from my-mind, so I care directly about unwrong-ing Mind, and am aware how received ignorance manupulates us into wrong-commitment. I want out. ], using impersonal system to cause the particular population to consider the issues, and work on the important/meaningful, getting important/meaningful result ( rather than the political ignorance/involvement-aggression we "want" ).

Any "answer" we put in Verisign/ICANN's place either will be made so it can work, or will be made so it won't ( rather than "can't" -- because of us ignoring human-nature and political gunk-nature etc. rather than because of any physics-level non-possiblity ).

This goes for all our governing entities and means ( whether state-corporation or privately-held corporation: no root-diff between 'em, just appearance+form difference ).

• which tasks they worked on yesterday
• how long they've spent on each task
• how much more time each task will take to complete
• what they're going to be working on today
• any blocking issues they might have

The project manager (who is not a developer and not a manager manager) is responsible for keeping track of the tasks and the hours and making that information available. It's always clear who has responsibility for what and who's blocking whom from getting their work done.

This does a great job of keeping developers productive, and since developers get to make their own estimates (and the total amount of work that can get done in a development cycle is based on 40-hour weeks), it also does a good job of keeping them sane.

(It works well with eXtreme Programming practices like pair programming and story-driven design, too.)

Reading the question, the point that sticks in my mind is that you admit to having even less project management experience than they have coding experience. Remember that as you think about replacing them with experienced people who know how to do the job they've been assigned. It seems to me that you need to stop doing their jobs and start learning how to do yours, which, like it or not, is being team leader and project manager.

Organization is also key. Read the last half of your second and third paragraphs again and tell me that you sat down and carefully organized your question. It's a careless error, but for someone who is complaining about their coding styles, it indicates a potential double standard.

What impresses me the most is that you seem to understand the solution needs to be found in management and methodologies but you don't discuss what (if any) methodologies you're using (although I'm suspecting waterfall right now).

Don't make them come to you. You're the leader. Be there for them, stay out of their way, and build trust. If you show leadership then they'll come to you. If you show tyranny, disgust, annoyance, or anything else, then they'll be happy to continue not producing anything in a vacumn.

Six weeks into a project with a tight deadline is not releasing code "early and often". In our world, six weeks is two iterations, each with their own deliverables, and a major iteration coming to a close. "Early and often" to many people means multiple code releases with full tests on a daily basis.

Remember, coders are no better than their enviroment. While you may have created an enviroment that works for you, it sounds like, as team leader, you've failed to create an enviroment that works for them. Perhaps it's time to put away 'your' piece of the project and start fixing the real problems.

Reading the question, the point that sticks in my mind is that you admit to having even less project management experience than they have coding experience. Remember that as you think about replacing them with experienced people who know how to do the job they've been assigned. It seems to me that you need to stop doing their jobs and start learning how to do yours, which, like it or not, is being team leader and project manager.

Organization is also key. Read the last half of your second and third paragraphs again and tell me that you sat down and carefully organized your question. It's a careless error, but for someone who is complaining about their coding styles, it indicates a potential double standard.

What impresses me the most is that you seem to understand the solution needs to be found in management and methodologies but you don't discuss what (if any) methodologies you're using (although I'm suspecting waterfall right now).

Don't make them come to you. You're the leader. Be there for them, stay out of their way, and build trust. If you show leadership then they'll come to you. If you show tyranny, disgust, annoyance, or anything else, then they'll be happy to continue not producing anything in a vacumn.

Six weeks into a project with a tight deadline is not releasing code "early and often". In our world, six weeks is two iterations, each with their own deliverables, and a major iteration coming to a close. "Early and often" to many people means multiple code releases with full tests on a daily basis.

Remember, coders are no better than their enviroment. While you may have created an enviroment that works for you, it sounds like, as team leader, you've failed to create an enviroment that works for them. Perhaps it's time to put away 'your' piece of the project and start fixing the real problems.

Reading the question, the point that sticks in my mind is that you admit to having even less project management experience than they have coding experience. Remember that as you think about replacing them with experienced people who know how to do the job they've been assigned. It seems to me that you need to stop doing their jobs and start learning how to do yours, which, like it or not, is being team leader and project manager.

Organization is also key. Read the last half of your second and third paragraphs again and tell me that you sat down and carefully organized your question. It's a careless error, but for someone who is complaining about their coding styles, it indicates a potential double standard.

What impresses me the most is that you seem to understand the solution needs to be found in management and methodologies but you don't discuss what (if any) methodologies you're using (although I'm suspecting waterfall right now).

Don't make them come to you. You're the leader. Be there for them, stay out of their way, and build trust. If you show leadership then they'll come to you. If you show tyranny, disgust, annoyance, or anything else, then they'll be happy to continue not producing anything in a vacumn.

Six weeks into a project with a tight deadline is not releasing code "early and often". In our world, six weeks is two iterations, each with their own deliverables, and a major iteration coming to a close. "Early and often" to many people means multiple code releases with full tests on a daily basis.

Remember, coders are no better than their enviroment. While you may have created an enviroment that works for you, it sounds like, as team leader, you've failed to create an enviroment that works for them. Perhaps it's time to put away 'your' piece of the project and start fixing the real problems.

I can't believe that no one has brought up Extreme Programming yet!

Many have mentioned pair programming, which will definitely help. But beyond that the prioitize, estimate, produce, analyze, repeat cycle will surely help as well.

When you miss your deadline you will have a. done all you can do and b. something that has 100% functionality on the top x% of features instead of something that has 100% of the features x% of the way to working.

Good luck.

=== ANSWER #1 ===
Do replace them.

Really, They are actually slowing *you* down. Motivate them into another job.

After that, hire a couple of proven contractors to catch it up. Contractors love short deadlines, and keep an eye out.

=== ANSWER #2 ===
You stupid bastard.

How long were they able to work without supervision? You are obviously not following any decent development methodology.

At this point, you need an XP style devlopment process in place.

1. Put SHORT (1-2 week) iterations in place.
2. Get a commitment of features that they will deliver.
3. Have them code them
4. MAKE SURE THEY WORK IN PAIRS. Now ordinarily, I'm not a advocate of pair programming, but these people obviously need constant supervision.
5. Install Web-tracking software on their PCs and/or the firewall. They are obviously losing the time somewhere, and it's probably due to web browsing.
5.1 alternativly, put a corporate firewall in place, and use a proxy. block 100% of the sites, and have a policy/procedure for adding sites to the "do not block list" at the proxy. Do they need to check Ebay/Slashdot/cnn/hotmail/farmchicks.com ? during working hours. Hell no.
6.[back to coding...] If they fail to deliver the promised code in the first iteration. FIRE THEM. Useless twits make all software development staff look bad.

Motivation is the wrong approach to use at this point in time. They are being paid to do a job. Do not continue to pay them for non-performance.

*whew*