Domain: extremeprogramming.org
Stories and comments across the archive that link to extremeprogramming.org.
Comments · 173
-
Re:XP Programming
XP does not suggest coding without considering design.
You obviously don't know anything about XP. Take a look. -
why Extreme Programming creeps me outBuzzwords:
"methodology" -- I suggest "method"
Philosophy:
"empowers" -- "lets"
"life cycle" -- ???
"groupware" -- ???
"XP is successful because it stresses customer satisfaction"
The What is Extreme Programming? page has these buzzwords and an "oily" tone in general. Like they're trying to sell something. Ick.
"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"
Stressing "customer satisfaction" is a good way to get a crap product. This echoes the attitude heard from Windows apologists: "Yes, but it's good for people who don't want to learn a lot about computers." For customers to have much input into the programming process is bad even for the customer. This is like letting managers overrule engineers in the Shuttle program.
Extreme Programming sounds like a way to pander to the egos of customers who want to "play computer", suits who think they know something and don't. Managers aren't programmers, they don't know how to program, and they should stay the hell out of the programming process. -
If it ain't broke (& has any measure o complex
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?!! ;^) -
Re:Great adviceI assume Joel is into XP, and XP practices really assume all the programmers are working together in the same space. Doesn't work so well from home.
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...
-
How ironic...Isn't it ironic that the Extreme Programming site is written in HTML 3.2 & JavaScript 1.0?
Markup languages are hardly extreme, but surely they could push the bounds of the latest standards and do something truely extreme.
;-)Mike
-
12 hour days?
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.
-
The test suite I use, and how I use XP
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.
-
Re:A witness turned him in?!?How on Earth do you witness somebody writing a virus?
Maybe they were following the XP-methodology and were pair programming?
-
Re:A witness turned him in?!?How on Earth do you witness somebody writing a virus?
Maybe they were following the XP-methodology and were pair programming?
-
Re:If in doubt, copy!
.. 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 is the way to goI find it interesting that not one of the high-score responses (I havent read the others) to this question has mentioned XP, i.e. Extreme Programming.
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 is the way to goI find it interesting that not one of the high-score responses (I havent read the others) to this question has mentioned XP, i.e. Extreme Programming.
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
-
no silver bullet
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. -
Sigh
If this ever catches on, we can say good bye to team work
-
Try calculate the cost of writing PERFECT proggies
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.
-
Extreme Programming?
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. -
Re:Too much integration is too limiting...
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
XP ( Extreme Programming) encourages "Refactor Mercilessly" which is what you suggest.
-
(1) Simplicity, (2) Simplicity, (3) Release oftenWell, well, well. You have just described almost every IT project in the history of the world. First of all, drop this fantasy that actually designign a fully normalized, big up front schema with a big up front design will save you anything but an ego. Again, GET OVER IT.
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.
-
No improvement because debug is the wrong tool!Debugging hasn't improved much because it's really the wrong tool to ensure program quality. Debuggers don't prevent coders from creating bad programs. At best debuggers are after-the fact, symptom oriented fire fighting tools that often point to more deeply seated problems than individual atomic bugs. Also, don't forget that in modern object oriented code, the old linear debugging techinques often produce results that are different than the actual program will because of threading, race condition and other issues.
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):
- Start with an Exploration phase, which includes:
- Meeting of developers, administrators and end users to discuss the nature of the problem and brainstorm possible ways to implement the solution.
- Create a rough prototype immediately (Frameworks like Naked Objects makes rapid prototyping like this easy).
- Go back to the meeting, have everybody play with the code and make more suggestions and changes. Demonstrate the prototype frequently to elicit feedback.
- Repeat (often) till people are mostly happy with the results.
- 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.
- Specification Phase:
- Use what you've learned to write a specification that includes lots of special case scenarios (use-cases, user stories etc.)
- Delivery Phase:
- Throw out all of the code you've already written... maybe keep the class and method names, but no actual functional code
- Write the tests FIRST. This includes unit tests, acceptance tests and corresponding documentation.
- Write the code to implement various user stories and test frequently.
- Auto-generate user training manual, which is based on the acceptance test code.
- Deploy to beta testers and be amazed at how happy they are with the product and how few bugs there are.
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.
- Start with an Exploration phase, which includes:
-
Re:Pair programmingPair programming does not merely increase quality of the output code, it is a fantastic way to perform knowledge transfer (either of specific code design, or general coding skills, depending on the relative skill level of those involved).
Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).
Chalk up one more piece of anecdotal evidence -- I've done it, and I recommend it.Does it always work, for everyone, in every project? That's an open question.
I have some doubt as to a theory that any one methodology can be a panacea. (This is why we have great holy wars over things like editors...)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.
Hear, hear. There are several standalone XP practices: code-to-the-test, pair programming, e.g. I recommend giving those a try first. If you can find an XP advocate with some experience, having them walk you through some of them has to be the best way to go about it. (IMHO). -
Re:the weakest link in XP
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?
It makes more sense for in-house development projects, where the "customer" already has an office in the building, and just reports to the programming bullpen* rather than to his/her own office/cube/whatever. The first serious XP development effort was an in-house project called Chrysler Comprehensive Compensation; the "customer" was the payroll department, and relatively easy to get "on site." XP has been strongly influenced by the patterns from that project.
*A lot of XP gurus like open space plans for development teams. YMMV.
The most common alternative to Customer On Site is Victorian Novel Requirements: the customers write hundreds (thousands) of pages of requirements (which can take as many staff hours as Customer On Site), throw the book "over the wall" to the development staff, and then complain when they didn't want what they originally asked for.
I agree Customer On Site may not always work. Lots of constant communications with the customer, in some form or another, is necessary for any successful software project, XP or otherwise. -
Pair programming
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
Right, that would be dumb; but that's not what XP calls for.
Pair programming calls for two people working together. At any given instant, only one person has the keyboard and mouse; but they get passed back and forth, and the person who's not typing is doing a lot more than "watching." It's as natural as two people designing together on a blackboard, once you get the hang of it.
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. The only way it'll be answered is if more people try to program in pairs.
The definitive book on the subject is Pair Programming Illuminated by Laurie Williams and Robert Kessler (Amazon.com, BN.com); recommended.
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. -
the weakest link in XP
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. -
Rules of Thumb
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. -
Two words:
Test first.
Thank you. -
Re:sacrificial lamb
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 -
Re:XP explained
This page explains what XP is, yet after reading it, I'm more confused...
They must have written this using the eXtreme Writing technique. -
Re:XP explained
Try this link for a well laid-out explanation of what XP is and how it {does | doesn't} work.
-
Re:sacrificial lamb
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!)
-
Re:sacrificial lamb
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!)
-
Re:That's too simple, way too simple
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. -
Re:Pair programming is not Extreme Programming
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. -
Re:But what is XP ?
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. -
Re:But what is XP ?
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. -
This is a very valid point, actually...
Check this out.
-
Balance of power
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. -
Easy Answer
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. -
Death March
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. -
Re:Good Resource
See also
And their main website
For other good XP programming practices. -
Re:Good Resource
See also
And their main website
For other good XP programming practices. -
XP says overtime is a no-no
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.
-
Why RUP doesn't work
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. -
Re:ICANNSIGN
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-res
p 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 ).
-
Sounds like you need some project management...You need someone (not you) riding herd on those developers and making sure they're actually getting work done. The company I'm at uses a lightweight process called SCRUM, where features (or "stories" in XP terms) are divided into small tasks, each developer is responsible for taking on and providing estimates for a fair share of tasks, and every morning there's a (short -- ten minutes, max) meeting where each developer has to go over:
- 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.)
-
Things to consider.Extreme Programming is a potential methodology to try. The use of pair programming in particular is something you should be looking at. Make them drive and you assist. Progress will follow. Some of the principles you already appear to be trying to follow, such as frequent small releases.
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.
-
Things to consider.Extreme Programming is a potential methodology to try. The use of pair programming in particular is something you should be looking at. Make them drive and you assist. Progress will follow. Some of the principles you already appear to be trying to follow, such as frequent small releases.
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.
-
Things to consider.Extreme Programming is a potential methodology to try. The use of pair programming in particular is something you should be looking at. Make them drive and you assist. Progress will follow. Some of the principles you already appear to be trying to follow, such as frequent small releases.
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.
-
Extre
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. -
It's been said, but..
=== 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*