Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Microsoft Lauds Scrum

ScuttleMonkey posted more than 8 years ago | from the sounds-like-fightin-words-to-me dept.

Microsoft 299

under_score writes "According to eWeek.com Microsoft is adopting the agile methodology called Scrum to get software built faster. Is it working? They seem to be claiming that Scrum and Extreme Programming have helped them get recent releases such as SQLServer out the door faster with better quality. Many other large organizations are also adopting agile methods including Yahoo, and Google. Are agile methods the next big thing in software development?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


Of course... (-1, Troll)

Keamos (857162) | more than 8 years ago | (#14019732)

Of course they're the big new thing in software--what isn't good about it for multi-billion dollar corporations? Faster to market, cheaper to make; of course everyone is doing it, until someone finds a huge flaw in how they do it and everyone is just like... "Oh...shit, oops?" and then they'll just find another method to quickly get beta-quality software to market to make big profits.

Re:Of course... (0)

Anonymous Coward | more than 8 years ago | (#14019766)

First to go is scoping (deliver less) then documentation and Testing,the success criteria. The patient has died, but the operation a success.

Re:Of course... (5, Insightful)

Anonymous Coward | more than 8 years ago | (#14019886)

The problem is that most managers have absolutlely no clue how to program or organize code. They can't really do anything useful in the design process. Each time something is built the programmers design and build everything without much more than stupidity raining down from the management team. Since managers don't know anything about the craft they're "managing," they don't recognize who is actually writting good code or designing robust systems and they tend to rely too heavily on the people who do nothing more than sit in the bosses office brown-nosing. As a result, many projects fail miserably or are badly designed, bug-ridden crap when they fianaly get called a "final" release. Since these managers are always having their own performance reviews tied to a process that they totally do not understand, they invent new "management" schemes to make it appear they are adding something to the process in an attempt to make themselves seem different from their peers. Until managers understand the craft they pretend to manage, we will all be subjected to feeble management fads.

So let's get this straight (5, Funny)

Anonymous Coward | more than 8 years ago | (#14019738)

Microsoft is lauding scrum for assisting them in delivering a product late and with a smaller featureset than originally planned? Ok, that's certainly an interesting approach. Now we can hear about how scrum is responsible for bringing Longhorn out earlier and with more features than ever expected.

In certain languages, such as Romanian. (2, Funny)

DaedalusHKX (660194) | more than 8 years ago | (#14019825)

"Scrum" means ASH... I guess... perhaps they refer to burning their products to the ground? Or what will be left of M$ once this latest FAD fails?

Please God let it be so!!


PS - don't you love being well traveled, and multilingual? Makes the world shine in new colors. (Now I need to learn french since they have really hot women.)

Re:So let's get this straight (0)

Anonymous Coward | more than 8 years ago | (#14019944)

Just think how late it would have been if they hadn't switched!!

Re:So let's get this straight (0)

Anonymous Coward | more than 8 years ago | (#14019995)

BINGO! XP is a big, red, shiny rocking-horse, all glittery on the outside but rotten on the inside.

The project that XP advocates always point to is the CCC Payroll Project at GM... software that was delivered late, required twice as many people as predicted, went over-budget by a factor of something like threefold, delivered only a subset of the original functionality and was eventually cancelled by GM. Rumour has it that it's a career-limiting move to mention XP methodology around GM execs.

Now, granted, scrum is a little "less crap" than many other XP methodologies, but that's like saying it's good that I only broke one leg, not both.

A good example? (5, Informative)

blowdart (31458) | more than 8 years ago | (#14019742)

So Scrum was used on SQL Server? The SQL Server product that's very late and has had to have features disabled [bink.nu] . Or was it used on Visual Studio 2005 perhaps? The one where they've already announced a service pack before the official launch date because people are so unhappy [microsoft-watch.com] ?

These are scrum successes? I'd hate to see the failures.

Could be.... (2, Insightful)

Steven Reddie (237450) | more than 8 years ago | (#14019788)

There isn't enough information to determine whether or not use of scrum was a success of failure. You're leaning toward failure, but it's just as possible that they switched methodologies toward the end in an attempt to get a late product out the door.

But that's typical. (5, Interesting)

blowdart (31458) | more than 8 years ago | (#14019896)

That's certainly true, but having read a lot about scrum et al you tend to find that most, if not all of the examples used to justify the selling of a new methodology don't have a lot of detail.

Take a look at one of the Agile Poster Children and his proof [agilemodeling.com] that it works.

Quote: "Because of the newness of agile methods there simply hasn't been sufficient time to prove that they work in a wide variety of situations."

Thats a wonderful way to dismiss anyone saying bad things, and it's rubbish, because the burden of proof for any claim is independent of its age.

Quote: "the question "where is the proof" is typically asked by organizations that fit the late majority or even laggard profiles ... Because agile techniques clearly aren't at that stage in their lifecycle yet I believe that this question simply isn't a fair one at this time."

So the act of asking for proof these things work means you're not ready? Ad hominem alert.

Quote: "Are they really interested in finding an effective process or are [they] merely looking for a reason to disparage an approach that they aren't comfortable with? Are they realistic enough to recognize that no software process is perfect, that there is no silver bullet to be found? Are they really interested in proof that something works, or simply an assurance of perceived safety?"

Ad hominem again.

Then you look at the project that started Agile, the Chrysler Comprehensive Compensation (C3) project. It was lauded as the first agile program and a success, however by February 2000 with the system was failing when paying 76,000 of the company's 86,000 employees. It was cancelled. Apparently this failure is now the new success [c2.com] .

Every methodology has rapid followers who will hear not evil said of it, but when looking at these things you have to remember "He's NOT the Messiah ... he's just a very naughty boy."

Re:But that's typical. (5, Interesting)

arivanov (12034) | more than 8 years ago | (#14020028)

Well, it tends to work in the areas where UML (in any of its incarnations) and the Unified Process reigns supreme. Now, the important thing before putting any claims about UML, object oriented programming and Agile is to understand the background behind their origins.

The Unified Process precursors were initially developed by consultants helping improve the code quality at Ericsson. The work was mostly in the area of voice switches and network management equipment. These consitute a specific field of software design which is quite different from the rest of the industry.

The most important difference is that there is an existing specification to which the software must comply. The specification already defines what the software is supposed to do for each allowed input, what are the error conditions, how to handle errors and this is usually defined as a set of simple and very strict rules. This type of task can be very easily expressed as a flow chart. The data objects are mostly defined in the protocol spec so there is no data design work to wrestle with. The spec rules are trivial to map to elementary state machines and are usually very small and well defined. They can be easily written with test cases and unit tested. And most importantly there is plenty of system resource to implement them.

While the methodology behind this type of work can be applicable to other fields there is no justification whatsoever to state that it is the only correct methodology.

It is not applicable to systems whose behaviour is mostly determined by a resource constraint.

In order to apply it to a system you have to define the specification first and express it in terms which are suspiciously similar to a Telecom switch spec - trivial actions with well defined input and output.

It is not applicable to systems where the conditions determining the change of execution are complex and cannot be expressed in terms of simple rules. Best example is possibly heavy duty math. It is nearly invincible to UML, UP and Agile attacks.

So on, so fourth.

Re:A good example? (0)

Anonymous Coward | more than 8 years ago | (#14019890)

Microsoft didn't "announce" a service pack before official launch. If you read the article, it claims that Microsoft has stated it would release a service pack in the future.

Of course it will... that's like saying that the linux kernel is bad, because they are going to release a 2.8 kernel in the future...

Doesn't make any sense...

Re:A good example? (3, Insightful)

zullnero (833754) | more than 8 years ago | (#14019947)

Ahh, typical XP newbies. The problem with most companies new to XP is they still want to do things the traditional way, ie., do it before a specified cutoff date. However, XP requires continuous releases, and Scrum is all about timeboxing each release. Soo...they probably tried to get too much done in too little time, went over the limit, realized that what they had wasn't acceptable, broke the XP rules, made some hasty fixes, disabled some harder to fix features, and got it out the door late anyway. The only reason I know that is because I've been through that.

XP isn't a magical cookie cutter solution you can just apply and expect instant $$, you pretty much have to build your team around it from the ground up, have experienced XP people around, etc. In fact, it really only works if the top level management really buys into it.

they almost get it! (-1, Troll)

twitter (104583) | more than 8 years ago | (#14019967)

from the fine article:

"The other is extreme programming-the concept where you might have two people working on a given piece of code and the idea is that two minds are better than one. Because you can find problems faster."

Treadwell said many teams within Microsoft rely on Scrum as a way to turn out quality software on time and in tune with user requirements.

and gentle reader, blowdart, notices The SQL Server product that's very late and has had to have features disabled.

Golly, Mr. Treadwell, just imagine if it were free software. Many eyes, shallow bugs, contributions from the user base, on and on. Oh yeah, that free stuff is why you have "extreme" programming methods and so much sweat. You will get there soon enough.

All laud the geniouses at Microsoft. One day, the great one at the top will get it and all will get it. Then, they might catch up and be useful again.

Doubtful about the speed (5, Insightful)

dnoyeb (547705) | more than 8 years ago | (#14019743)

I find methodologies are like other tools. If they buy you time, and your dilligent, that time will be spent on quality. So its not likely to both buy you time & quality. If you seem to have more time its only because you have not spent it on quality.

Re:Doubtful about the speed (3, Interesting)

aussie_a (778472) | more than 8 years ago | (#14019760)

With Microsoft's virtual monopoly, they have a guranteed market for a program and would have to cock it up REALLY, REALLY bad for that market to shrink to a noteworthy degree. So they need to get programs out there to rake in the cash. Quality isn't really an issue for them.

However hopefully if they continue to use this flawed business plan, they'll continue to slowly lose customers. Well, I can dream, can't I?

Re:Doubtful about the speed (1)

jcr (53032) | more than 8 years ago | (#14019784)

they have a guranteed market for a program and would have to cock it up REALLY, REALLY bad for that market to shrink to a noteworthy degre

Well, they've certainly done so, for many years running now. Isn't the power of inertia amazing? It's keeping them up now, but once they hit the tipping point, there'll be no saving them.


Insightful?! (5, Insightful)

RAMMS+EIN (578166) | more than 8 years ago | (#14019996)

Sorry about whining about a post getting modded up, but what is this? Can't people calculate anymore? If Scrum buys you two months of time, and you spent half a month on improving quality, hasn't Scrum bought you both quality and time?

The above is just a simple counting argument. But if you actually look into the nature of things, it's entirely likely that a better process can increase development speed and improve quality. For example, if you improve the specification process, you could end up with a clearer specification that wouldn't be adapted so often while implementation is already going on. This reduces the time it takes to implement the specification, and causes it to be implemented better.

So, no, I don't think the parent is right that you can't have an improvement in both time and quality, or that if you've improved one, it's probably because you sacrificed the other. I do think that a lot of these methods are worse than worthless, but that's a completely different story.

Scrum defined (0)

Anonymous Coward | more than 8 years ago | (#14019746)

Don't do meetings all day and get coding instead! D'uh!

This is a new thing? (3, Insightful)

sparkhead (589134) | more than 8 years ago | (#14019749)

From the article: So Scrum is one process--the idea that teams meet once a day for half an hour, figure out what they're going to do then go off and do their work very quickly.

Well, yeah, we call that a daily team meeting. Been going on since, oh, forever.

As far as XP goes, don't think that's going to be a hot methodology for too much longer.

Re:This is a new thing? (1)

jarich (733129) | more than 8 years ago | (#14019777)

Two things.

First, Scrum is a lot more than daily meetings. That's one practice among half a dozen.

Second, a Scrum daily meeting is 1 to 2 minutes per developer. If they're meeting for 30 minutes, the teams are too big.

Re:This is a new thing? (1)

leonmergen (807379) | more than 8 years ago | (#14019826)

Exactly. And another major advantage of SCRUM is that it enables companies to always have a product they can (theoretically) ship... that's very cool for the sales, marketing, etc people...

Always shippable is not new (0)

scattol (577179) | more than 8 years ago | (#14019909)

Having a product that is always shippable is NOT new. In fact I've been doing this since the early 90's and I am sure that it's how it was done decades before that.

I mean this is the core concept of source control. What you have under source control is shippable, and ideally QAed enough to know for sure that it hasn't been badly broken. If you can't acheive that, you have absolutely no control over your sources and I seriously doubt you have any idea about what your schedule will be 4 weeks down the road.

Re:This is a new thing? (5, Insightful)

sparkhead (589134) | more than 8 years ago | (#14019910)

I checked out the Wikipedia entry on Scrum, and if you'd like to fill in the missing details, please do so. What it says is in bold, what I would call it is not:

Characteristics of scrum

* A living backlog of prioritised work to be done;
An updated prioritized bug and feature list.
* Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
Picking a set of items and fixing them quickly.
A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
Progress and issue review.
A brief planning session in which the backlog items for the sprint will be defined.
A brief heartbeat retrospective, at which all team members reflect about the past sprint.
Post mortem review.

What's truly new here? I'm not asking to be a wiseass, I genuinely would like to know what this is apart from relabelled standard practices.

I went to the Control Chaos site on Scrum and the header states "It's about common sense". OK, so why give it a stupid label with overblown descriptions? The "what is scrum" section on that site reads like a Dilbert strip.

Re:This is a new thing? (1)

OneOfThree (599373) | more than 8 years ago | (#14019989)

The ideas aren't new. What is new is the way they are brought together and emphasised. So what's different is that there is higher concentration of best practices than in your typical development process.

Re:This is a new thing? (5, Insightful)

Anonymous Coward | more than 8 years ago | (#14019992)

The news is (or was when Agile first came about) was packaging these practices into a methodology. And giving it a name - a name, as we all know, is the most important part of a project.

Ten years ago, and often still today, a mainstream software engineering textbook started with "design errors are expensive to fix while programming". Which is a slippery slope that inevitably leads to the Waterfall Model.

So most companies (not all!) took the Waterfall Model as an unquestionable law of nature. Monolithic upfront requirements specifications carved to stone, etc.

Agile methodologies _think_ about the "obvious to any hacker" process and _measure_ it. They take what looks like chaotic uncontrolled hacking and, by thoughtfully selecting the right parts of the chaos, make something that can be directed to achieve the desired result.

Sure there have always been programmers who used bits and pieces of Agile tricks. But rarely in a controlled, designed, documented, measurable way. Not in a way that is taught to every new employee, which is what you'd do with a systematically applied methodology.

If you have for decades systematically used a well-thought-out collection of Agile principles you should have written a well-argued book that proves how your methodology kicks Waterfall Model's butt. If you aren't a book-writing kind of guy you could have ghosted the book. It's too late now to say "I always used a provably better methodology than the Waterfall Model, I just never bothered to tell anyone" :-)

Re:This is a new thing? (0)

Anonymous Coward | more than 8 years ago | (#14019820)

You clearly miss the point. You see - scrum is a new methodolgy for execs to leverage to their team-mates so as they can engineer new solutions for the problems faced by the modern day office cowboy.

Re:This is a new thing? (5, Funny)

Spit (23158) | more than 8 years ago | (#14019867)

No, Scrum is different. Scrum is a daily meeting that is EXTREME TO THE MAXX!!

Re:This is a new thing? (5, Informative)

bwy (726112) | more than 8 years ago | (#14019899)

Well, yeah, we call that a daily team meeting. Been going on since, oh, forever.

The daily stand-up is only a small component of Scrum. And the purpose of the meeting is strictly related to which tasks from the sprint backlog you were working yesterday, which ones you'll be working today, and whether or not you have any impediments. Only pigs are allowed to speak in the daily stand-up. This means that chickens (product owners, business folks, etc.) are only observers and can't butt in and introduce scope creep. How many times in a traditional waterfall methodology have you had someone add to your scope in a daily meeting? Every day they want to change a page, add a column to the database, change the way something works, etc. This goes on to the point where the product never gets delivered. Under scrum you deliver something every 30 days and at that point the product owner can decide if he really wants to change something- and he does this by adding it to the product backlog- not by grabbing someone in the hallway.

Re:This is a new thing? (1)

maharg (182366) | more than 8 years ago | (#14020075)

Hear hear. Where I work, we have been using scrum for a couple of years, it works very well for us. We have 2 week sprints for finer granularity of deliverable code, and use XPlanner (http://www.xplanner.org/ [xplanner.org] ) for tracking the product backlog and sprint stories / tasks - XPlanner displays sprint progress in the form of a burn-down graph, which is great as you can see at a glance how well the sprint is going. As pigs also positively encourage chickens to attend, and that's very useful for everyone.

Re:This is a new thing? (1)

connah0047 (850585) | more than 8 years ago | (#14019913)

As far as XP goes, don't think that's going to be a hot methodology for too much longer.

I'm interested in your opinion...why do you believe that to be true?

Deadlines (4, Insightful)

aussie_a (778472) | more than 8 years ago | (#14019751)

Looks more like developers are being pressured to achieve ridiculous deadlines, with a fancy name tacked onto the pressure. I also wonder what sort of security is being done to programs developed via the scrum method. Is the scrum JUST for the programming (and/or the preceeding stages)? Or is it the whole thing, testing included, in this "quick, quick" method? If it's the latter, I can't see how testers are going to be able to truly secure the software, so we'll continue to get unsecure software from Microsoft. Thanks a lot, you just made my wish to migrate to Linux increase.

Re:Deadlines (1)

DaedalusHKX (660194) | more than 8 years ago | (#14019846)

If you want help migrating to linux, I'd be glad to help, lemme know what kind of machine you have (specific hardware, age of rig, etc, what you're running and what you want to run it for). I also want to know how tech savvy you are since that will play a big role in which linux distro I'd recommend. (if you say Doom3 and Quake4, I will only say "Gentoo Linux"). Those games have Linux clients, and if you prefer just using the windows installers you can always just use Cedega or Wine.


PS - I am extremely busy during the week, but I do get around to answering questions or helping people at night (on shorter days :) at least until I get my new wireless laptop, then I can help from wherever.)

Re:Deadlines (1)

aussie_a (778472) | more than 8 years ago | (#14019858)

Wow, thanks a lot for the offer. I've tried numerous times in the past (with and without help from nice people like you) and in the end there's always one necessary feature that doesn't work. So at the moment I'm not looking to migrate to Linux (especially with having a family who uses the same computer, having to reboot it whenever they wanted to hop on would become a pain. And they refuse to use Linux even if I -did- get it working). In a couple of years once I've got a place of my own I'll definitely be looking to move to Linux, and hopefully by then the few apps I've got that are Windows only will have been ported to Linux, or comparable alternatives would have been developed.

Tell me what apps you are referring to (1)

DaedalusHKX (660194) | more than 8 years ago | (#14019897)

And I might have either drop in alternatives or something that does the job... A lot of your apps will run absolutely fine in Wine. Even internet explorer runs in wine (it actually runs better because spyware you will invariably incur using that Piece of Crap (tm)(c)(R) will not bork up the entire system, just the fake windows install that your apps think they're using.


PS - "why" does your family refuse to use linux? It isn't as if the "my computer" button can't be created to point to /home/familymemberinquestion directory :) I'm not being mean here, I'm simply curious what makes for such vehement denial (my mom's not a geek but she prefers solaris at work, linux at home, and hates being stuck on "such a slow system" (her 2.2 ghz windows box, vs the Solaris Ultrasparcs she occasionally logs onto at work, if she can adapt, heh heh, my father made the excuse that he doesn't know anything except windows, but since all he does is surf the web and check email/orders he has little reason to complain once I put a firefox/evolution link on his desktop, I run a fully patched version of Xine with the matroska codec pack on his rig as well, he likes to rip movies to the file server and then watch them on his comp... all doable).

I'm not asking you to migrate, I'm simply curious (1)

DaedalusHKX (660194) | more than 8 years ago | (#14019917)

I just want to know why your family is so against migration, (and I'm still curious about the apps you can't get replaced in *nix, I know there's a couple that are hell to get working and some that don't exist, but the number is getting extremely small as of late).


But will our management buy it? (2, Interesting)

Elrac (314784) | more than 8 years ago | (#14019754)

I'm happy to hear that XP practices are helping some high-profile companies. Alas,
  • I work for a company that adopts new trends at least 5 years late - that's about when they're being phased out elsewhere. For example, we're now deeply committed (or should I say sentenced?) to J2EE, RUP and outsourcing;
  • Our company works on a contract basis, with complete and "firm" specifications (BDUF, anybody?) going in and deliverables coming out, with no wiggle room, no negotiation (at least from our side), no onsite customer.
Given such an environment, which I'm sure will sound familiar to others, do we stand a chance of ever being able to work this way too?

Lucky You (5, Insightful)

RAMMS+EIN (578166) | more than 8 years ago | (#14020065)

I say you're lucky. I'd much rather work for a company that watched what $new_thing is doing to others before adopting it, than one that jumped on every overhyped new thing that hit the press.

There is an unholy amount of crap being invented and hyped everywhere, and, in my experience, the things that are being hyped the most are never the best ones, or they aren't actually anything new.

A few examples:

  - Java, when new, was being hyped up the wazoo. This was the herald of object oriented programming and write once, run everywhere. Never mind that object oriented programming languages had existed for a long time, as had write once, run everywhere, and that Java isn't actually a particularly nice programming language (I get modded down every time I say something negative about Java, but this time I assume at least you will read it). With the advent of Java 5.0, it got a lot better, with things like generics and "foreach loops"; the performance problems have mostly been worked out, and stable and mature frameworks have been developed. And now your company has adopted it. Makes sense to me.

  - Ajax is the new hype of the website scene. All it is about is making websites more like regular applications through the use of existing technologies. I was doing this stuff in 1997, possibly earlier. It's still majorly broken in the exact same ways (you need to use a full HTTP request to get new data, and the server can't push data to you, except on some implementations). Maybe in five years these things will have been fixed (perhaps with the advent of XAML?) and your company will adopt them?

  - RSS feeds are all the hype. Basically, you can get news headlines from sites you subscribe to. It works just like regular HTTP, except that people have standardized on a, no, two, no, four formats to distribute headlines in, so that they are sort of compatible between implementations. Maybe in five years, when your company adopts the technology, there will be a single standard format? And maybe they will have solved the problems caused by the fact that data is being pulled (by clients who don't know when updates are available), instead of pushed (by providers who do know when content is available)? We shall see.

I could go on, but I think you get the idea.

Thought this could help (2, Informative)

exaviger (928938) | more than 8 years ago | (#14019755)

Had no idea what Scrum is so found this

What is Scrum? Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. It's attributes are:
* Scrum is an agile process to manage and control development work.
* Scrum is a wrapper for existing engineering practices.
* Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing * Scrum is a process that controls the chaos of conflicting interests and needs.
* Scrum is a way to improve communications and maximize co-operation.
* Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.
* Scrum is a way to maximize productivity.
* Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.
* Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

Original article can be found: http://www.controlchaos.com/about/?SID=8ef7eb5b2a0 69a2710abef27d02c851f&SID=7da824062baf60b8e78ec5f9 9836f092 [controlchaos.com]

Re:Thought this could help (1)

Doppleganger (66109) | more than 8 years ago | (#14019786)

Sounds better than the list I got..

scrum is in fact much more predictable and effective than manufacturing
scrum is also awarded whenever a pass is made in which the ball goes forward
scrum is an impossible dream
scrum is to restart play quickly
scrum is "back foot"
scrum is forbidden
scrum is awarded at the place of infringement
scrum is very different to a gridiron scrimmage

Rats, maybe Googlism wasn't the best place to look. Though, if it's anything like some of the other programming method buzzwords out there, the "impossible dream" one might be onto something...

I prefer this definition (5, Funny)

ColourlessGreenIdeas (711076) | more than 8 years ago | (#14019908)

http://www.scrum.com/rugby_guide/scrums.asp [scrum.com]

Do that every time you need to make a decision. Clear all furniture out of the way first.

Re:I prefer this definition (1)

middlemen (765373) | more than 8 years ago | (#14019981)

The dictionary.com definition says :

scrum n.

      1. Sports.

                  a. A play in Rugby in which the two sets of forwards mass together around the ball and, with their heads down, struggle to gain possession of the ball.

                  b. The mass or formation of players during such a play.

      2. Chiefly British. A disordered or confused situation involving a number of people.


Clearly Microsoft is going for the definition 2. above!! They are trying to use British words to fool the American management.:)

Tenuous link to facilitate a dig at the Aussies... (1)

Dan-DAFC (545776) | more than 8 years ago | (#14020057)

On yesterday's evidence [bbc.co.uk] , we should hope that Microsoft have been modelling themselves on an English scrum rather than an Australian one.

Agile can help (0)

jarich (733129) | more than 8 years ago | (#14019758)

Agile methods, properly used, are the best way I know to improve product quality, keep a handle on what everyone's doing , and improve the developer's skills.

It's not a silver bullet but a very useful tool. Even if you don't adopt them wholesale, you should take a "survey course" to see what it's all about. Pick a few of the practices and try them out. See what works for you.

At the risk of sounding like a shill, check out my book (or one like it) to a quick intro some agile methods.

http://www.pragmaticprogrammer.com/titles/prj/ [pragmaticprogrammer.com]

New Big Thing (2, Insightful)

alnya (513364) | more than 8 years ago | (#14019767)

This is something else to be looked at and might well be a good approach. Of course, in reality, the best thing to do is to cherry pick parts of methodologies you like and that work for you. We tend to use test-driven development in conjunction with agile techniques and that works for us - everyone is different. I've yet ot see a fully agile approach be successful however (in an "on time on budget fully featured sort os definition). Of course, YMMV.

The next big thing... (0)

Anonymous Coward | more than 8 years ago | (#14019769)

or the next buzzword for managers?

For my part, I hate having someone sit at my desk and debug with me for 10 minutes; XP sounds like torture that would cancel out any advantages it might have.

An awful lot of these things (from "methodologies" to the latest fads in "design patterns" and C++ template overusage) sound to me like coders who saw the writing on the wall when the first shop opened in Bangalore and started looking for something that would get them published / get them tenure / give them an "expert in" edge in the consulting market. I can't fault people for going into business for themselves (I have a family too) but it sure is annoying to deal with the consequences.

Re:The next big thing... (0)

Anonymous Coward | more than 8 years ago | (#14019950)

This one is also for management. Always ready to ship and quick cycle times are perfect for PHBs who have no idea of exactly what they want, want it yesterday, and arrive at product design by successive approximation, and wonder why their Achilles never catches the tortoise.

Sure, SCRUM has all sorts of things to prevent that (don't they all?), but pick-and-choose buffet-style adoption of a methodology will short-curcuit that.

Combatting OSS (2, Informative)

Kawahee (901497) | more than 8 years ago | (#14019774)

I think it's a new method to combat OSS. It's been long known that OSS is fairly slow to come around, and so far, Windows and that has taken a long time, too. But if Microsoft can push out the next version of Windows/Office/VS .NET faster and with a higher quality of code, potentially they can take on OSS faster and harder than ever before.

And I'm not talking upgrading software, like VS .NET 2007 or Office 13 (lucky), but also new software, if not new software from codebases such as Microsoft Tool X or Tool Y, like the Speech SDK that they've got out there, - or any other Microsoft Research project.

Wrong question! (-1, Offtopic)

KZigurs (638781) | more than 8 years ago | (#14019781)

The real question should sound: "Is linux ready for desktop?"

Re:Wrong question! (1)

afd8856 (700296) | more than 8 years ago | (#14019830)

Short answer: Yes
Long answer: Hell, yes.

Start trying one of the recent linux distros, they're very good. I'm using Ubuntu, if that helps.

I'm using Gentoo :) (1)

DaedalusHKX (660194) | more than 8 years ago | (#14019879)

And yes, VERY easy... and at least I didn't have to hunt for drivers to have my brand new, Athlon X2 board running on Linux... I spent a whole day troubleshooting the issue with my nvidia motherboard drivers in XP (the gaming side for this rig, I have a few games that DONT run in linux... and as I've said many times before, the only reason I keep XP on this rig is to game, Starcraft, all the Warcraft games, Doom 1 2 3, Quake 1 2 3 4, Unreal, UT, Half Life, Hexen 1 2, Heretic 1 2, all run in Linux without issues using Wine or native clients (Q4 and D3). I haven't checked Half life 2.

Overall I'd say that since I do NOT trust Windows with my business and only do my banking and important email from my linux box.


big things (3, Insightful)

famebait (450028) | more than 8 years ago | (#14019791)

Are agile methods the next big thing in software development?

No, they are the current/i> big thing. No doubt the hype will pass, but I do hope and believe and they bring some things to the table that deserve to last.

The focus on the way people actually work, on optimising that in a realistic way, on work satisfaction, on recognising and handling uncertainty in stead of ignoring it, and on pulling the curtain on a lot of practices that everyone knows don't really work but kept pretending anyway. All long overdue lessons for a methodology-field too long too dominated by good-on-paper theory and wishful thinking for managers rather than real experience with what works.

Re:big things (2, Interesting)

marcosdumay (620877) | more than 8 years ago | (#14019924)

My guess is that XP is working only because it banished the "good on paper" metodologies and because of the refactoring formalism. All the other points you cite are a description of "good management", and as so, don't change just because the company adopted another metodology. But getting ride of a lot of useless paper (by letting the programers decide what is usefull) is the way to go.

Agile methods are not the next big thing (0)

Anonymous Coward | more than 8 years ago | (#14019803)

They are the last big thing. They were the next big thing five years ago. Under which rock did the article's author live?. They have gone the way of the hype. They are as much the next big thing as FORTRAN.

Why XP works when it works. (5, Insightful)

ankarbass (882629) | more than 8 years ago | (#14019809)

When XP works, at least in some cases, it works not because it's the best methodology. But because it is the one that people will do. It is "A" methodology where there either wasn't one, or there was something in name only which people paid lip-service too. For the programmer and manager alike, XP is easy to grasp and start implementing right away. Compared to more traditional methods, it's a simple method that eschews excess paperwork and you can explain the basic idea over lunch.

I also think there is something to the transparancy of the work environment. It's a lot harder to read slashdot when you are "pair-programming" or all of your peers are sitting in the center of a large room. It might just be that you get more done because it is harder to slack.

Re:Why XP works when it works. (1)

ankarbass (882629) | more than 8 years ago | (#14019818)

Of course I meant:

When XP works, at least in some cases, it works not because it's the best methodology, but because it is the one that people will do.

and I even used preview, damn it!

Easier actually to slack off (1)

CarlBenda (645559) | more than 8 years ago | (#14020016)

I did pair programming in an XP environment at one company for six months before leaving. It's actually a hell of a lot easier to slack off. If a company hires good programmers the one doing the typing does almost all the work while the other person tries desperately to keep awake. After a while it's easier staying awake and waiting for a point to look over code by reading slashdot or whatever.

An XP Book Review... (3, Informative)

mindpixel (154865) | more than 8 years ago | (#14019827)

This is a very timely posting for me...Monday I have a meeting to get the budget to make create an XP team to build Ajax internal systems. Good to see the large entities are thinking the same way.

Here is my review of Ron Jeffries, Extreme Programming Installed from April 25, 2001:

People are starting to take XP very seriously simply because it delivers quality code instead of just documents about code. The core philosophy can be summed up: "A feature does not exist unless there is a test for it." (P.83) This means that coders (pairs of programmers in XP) first construct unit tests of product features before the attempt to code the features. What this means in practice, is that the code that XP delivers (continuously in 3 week long iterations) can never be broken! I'll say that again just to make sure you read it: XP code can never be broken! I really think XP's adaptive, test-first philosophy is the best thing that has happened to software engineering since Dijkstra told us that the "Goto Statement is Considered Harmful" in 1968.

This book is the best of the XP series if you've actually made the decision to use XP. If you're not sure about what XP is or what it's limitations are, go to google and do your homework. When you're ready to actually install an XP project, get this book.

So how do you write tests for .. (2, Interesting)

RedLaggedTeut (216304) | more than 8 years ago | (#14019869)

So how do you write tests for ..

- applications that are a constantly moving target "this would be cool to have"

- applications where the moving-targetness lies in the presentation, while at the same time some customers bitch about any change in presentation

- applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data.".

Re:So how do you write tests for .. (1)

sqlrob (173498) | more than 8 years ago | (#14019898)

-applications that are a constantly moving target "this would be cool to have"

The tests are feature based. Write one for the new feature.

- applications where the moving-targetness lies in the presentation, while at the same time some customers bitch about any change in presentation

XP doesn't work here. The only thing that does is application of extreme violence to the customer.

- applications with changing data sets - you can run your tests fine on the standardized data set, but then when it hits the real-world data, all you can say is "Sorry my application is perfect, it just doesn't work with with that data.".

You file it as a bug, use the data that caused the failure in a new test.

Re:So how do you write tests for .. (1)

davecb (6526) | more than 8 years ago | (#14019915)

As to the changing data, take a pair of techniques from the database world. If
- you can always add a column
- you have a "nil" value to stand in place of any missing data, and
- all your calculations know that nil + 1 = nil, then
Your existing program can still do all the computations that are defined on whatever data they give you.

Then report the data change as a bug and write code for it, too.


Re:So how do you write tests for .. (1)

the eric conspiracy (20178) | more than 8 years ago | (#14019970)

You file it as a bug, use the data that caused the failure in a new test.

The problem we face is that the failure is in the arena of performance, and it occurs on a Sun E15K with a 20 TB database on an EMC box at a customers site. And we don't have anything remotely close to that level of hardware available internally, nor will we ever. And everytime we propose infrastructure improvements in the software they don't make the development schedule because they are bumped in favor of features that the sales force has already committed to delivering.

XP level of testing leads to brittle code (2, Insightful)

CarlBenda (645559) | more than 8 years ago | (#14020038)

Have you done XP programming yourself? Evidently not. Did it for six months at one place. We had so many tests that whenever a refactoring was done it would break tons of tests. The tests would have to be redone thus decreasing their value. The tests weren't making sure new changes didn't break the code because whenever you added new code you changed the tests. Refactoring thus wasn't encouraged by all these tests and so eventually you have more and more spaghetti code. Our XP coach was telling us that every so often it's hard to move forward and someone has to go in and change things while others wait. Yeah we figured out what he meant. The code got so bad (even though all tests were passing) that someone had to go across the whole code base and spend a week fixing junk. This happened over and over.

eXtremeProgramming.org last updt'd Feb 2004 (1)

ivi (126837) | more than 8 years ago | (#14019832)

  They must be doing something right - ie,
  if they can leave eXtremeProgramming.org
  untouched (& feel it's just fine) since
  early 2004, eh?

Repeat One Million Times... (0, Redundant)

Detritus (11846) | more than 8 years ago | (#14019862)

Repeat One Million Times...

There is no silver bullet!

If you still don't understand it, go to step one.

Something else might be going on here (0)

Anonymous Coward | more than 8 years ago | (#14019928)

This might be more than some pop superficial rehashing of programming methodology. This is an example of arbitrarily changing the rules to reduce competition. After all, they could have dragged out the old papers and books on formal programming process by Fred Brooks et all and used those. But by making up new rules (actually a subset of the old rules with new names) you can exclude competition from the programmers who know the old rules since they won't be familiar with the new names and will commit faux pas like asking for a formal specification or code reviews which aren't things in the current subset du jour.

Re:Repeat One Million Times... (0)

Anonymous Coward | more than 8 years ago | (#14020045)

> There is no silver bullet!

Correct. There are good tools though. It is useful to be able to recognize good tools when you see them, instead of going "hmm, this tool does is not a hammer AND a screwdriver, so I'll ignore it."

Which do you find best: waterfall model, agile, or ______ (insert your methodology).

I find agile a lot better than the waterfall model. And I'm not smart enough to invent, prove by repeatable measurable experiments, and document a better methodology from scratch. So I'll go with agile until someone comes up with something better.

Re:Repeat One Million Times... (0)

Anonymous Coward | more than 8 years ago | (#14020064)

If there are no silver bullets, why am I limping?

Developer's opinion of scrum (3, Interesting)

Anonymous Coward | more than 8 years ago | (#14019929)

I'm a developer at a smallish company (~25 developers) which started using scrum in August. I was very skeptical at first but really like it now. The short version:
Previously management just did whatever felt right.
Sometimes this was very good, sometimes it was very bad. Sometimes it was just inconsistent.

Now management has a defined methodology that they follow. There are some rules. The rules need not be particularly great ones (although I don't mean to suggest scrum isn't good), just so long as management is thinking about them and makes a concious decision to be consistent and let develoeprs know what to expect.

Specifically, scrum has helped us overcome the "holy shit, its a big customer bug!" panic that happened occasionally. We still panic, but its not the entire organization jumping onto one bug, its just a single scrum team.

Posting as AC, as my coworkers AND management read slashdot and will recognize me.

Guru following (0)

Anonymous Coward | more than 8 years ago | (#14020044)

"Previously management just did whatever felt right."

You make it sound like they pulled decisions from their ass. They presumably had knowledge of the product and the market your product addresses, something the makers of the methodology don't have. At worst they were as ignorant of your products as the methodology makers are.

Why would you choose a blind person with a good sales patter over someone with sight of the product and market? If methodologies are good, then why are there so many of them? Wouldn't we gradually refine to just one instead of inventing a new one every few months? Isn't this just Guru following, a new Guru comes along with new names and a new sales patter and managers with little confidence worried about their projects follow the Guru.

"Posting as AC, as my coworkers AND management read slashdot and will recognize me."
Or you're part of the sales patter, you've said nothing controversial that warrants an AC.

Remote pair programming is the "next big thing" (3, Insightful)

Carl Rosenberger (449479) | more than 8 years ago | (#14019939)

Agile methods have been around for a long time, they are not new, it's only new that big companies like MS find out that they work indeed.

In the meanwhile globalisation has advanced, there is a more efficient way to build software than to pile people up in cubicles. It's pretty much like an open source project:
- Get the best experts from all over the world for the theme where they are good at.
- Let them work from home.
- Let the team work in remote pairs, using VNC and Skype and change pairs frequently.

In this setup half-hour meetings every day do not work, because of the different timezones. A weekly meeting is good enough, Asterisk works fine for VoIP conferences, CVS email notifications about all checked-in work keeps everyone up-to-date.

This is how our company works. We are very happy with the cost and the quality of the work we get and with the lifestyle to work at home when you want and how you want.

scrum experience (3, Interesting)

AgentPhunk (571249) | more than 8 years ago | (#14019941)

I used to work in a scrum-based web development shop.

Meetings went something like this:
Go around the room, and say #1 - what am i going to do today, #2 - whats in my way of getting #1 done. One two people were allowed to talk, the person who's turn it was, and the manager in charge of the meeting. If another person in the meeting was the cause of someone's #2, the manager would turn to them, give them (and only them) them the chance to respond. Lather rinse repeat.

There was no "I did this yesterday" because a) we supposedly heard about that the day before, b) the assumption was that you got it done.

Even with at least three different projects going on, and maybe 15-20 people in the room, we were out of there in 30-45 minutes. Any major issues were taken offline so that the rest of us could get back to work.

We usually had only one meeting a day, sometimes two. I found it worked extremely well with a minimal amount of thrashing. We might have been using a modified version of scrum; can't remember - those were dotcom days, everything's still a blur.

Re:scrum experience (1)

AndroidCat (229562) | more than 8 years ago | (#14020022)

One or two 30-45 minute meetings per day...? Work out the average hourly rate x 15-20 people and that's quite an expensive overhead. Did the people from all the different projects have to be in the same room with each other?

Bah. That's nothing new (2, Funny)

Anonymous Coward | more than 8 years ago | (#14019946)

Rugby's had scrum [wikipedia.org] for years.

Agile & Scrum work for us (4, Interesting)

ameline (771895) | more than 8 years ago | (#14019949)

At Alias, we use Agile and Scrum very extensively. The Sketchbook team was among the first at Alias to adopt it at our company -- Jim Highsmith even gave us a little write up in one of his books.

We don't, however, do that much pair programming. And the whole completely open office space works for some, and definitely not for others. For myself, I'm way too easily distracted -- so I need a nice quiet and private cubicle in order to achieve the state of "flow" where I can write code. In my experience, pair programming works for debugging and integrating code -- and not so well for creating it. YMMV.

Sketchbook has come in on time and on budget, and with extremely high quality. Agile and Scrum had something to do with it. I think the fact that we had a clear vision, a small and very experienced team, a really good working relationship with our usability team and research team, great QA, and excellent management had at least as much to do with it.

As a process, its the only one I've seen in 20 years of doing this that actually makes the life of a programmer better, not worse.

Re:Agile & Scrum work for us (1)

russh347 (316870) | more than 8 years ago | (#14020049)

In my experience, pair programming works for debugging and integrating code -- and not so well for creating it.

How odd. In my experience pair programming works really well for writing code... and, together with TDD and other practices, dramatically reduces the need for debugging.

I don't see.. (1)

OreoCookie (814421) | more than 8 years ago | (#14019957)

anywhere in the article where it says they used SCRUM or Agile Programming on SQL 2005. It says they are unhappy with the length of their release cycles and are going to try XP as a way of speeding them up.

Death by Buzzword (4, Funny)

RAMMS+EIN (578166) | more than 8 years ago | (#14019964)

Ok, so what's this scrum thing? According to Control Chaos [controlchaos.com] (the first related hit I got on Google):

Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.

Lots of buzzwords, little information. So let's Learn more [controlchaos.com] :

- Scrum is an agile process to manage and control development work.

  - Scrum is a wrapper for existing engineering practices.

  - Scrum is a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing

  - Scrum is a process that controls the chaos of conflicting interests and needs.
Scrum is a way to improve communications and maximize co-operation.

  - Scrum is a way to detect and cause the removal of anything that gets in the way of developing and delivering products.

  - Scrum is a way to maximize productivity.

  - Scrum is scalable from single projects to entire organizations. Scrum has controlled and organized development and implementation for multiple interrelated products and projects with over a thousand developers and implementers.

  - Scrum is a way for everyone to feel good about their job, their contributions, and that they have done the very best they possibly could.

At this point, my head exploded. This note is a post-mortem plea to press murder charges against the person who wrote that crap.

vapor style (3, Funny)

opencity (582224) | more than 8 years ago | (#14019974)

So Scrum is the idea that teams meet once a day for half an hour, figure out what they're going to do then go off and do their work very quickly.

Wow, genius.

(from what little I know) Extreme programming is testing constantly and having people work side by side? Well I Am Not A Professional but I figured this out after my first project got too big. Am I missing something here?

I've got a new methodology: It's called: "Inning". Your programming team works for an 8 - 14 hour period and then takes a break when they sleep. I like to combine it with "Lunch" where the team, either together or seperately, eats food periodically during the day. My book is available to preorder.

It depends.. (1)

d_jedi (773213) | more than 8 years ago | (#14019978)

On how it's implemented within the company. The daily meetings can become a huge waste of time if:
a) There are unnecessary participants
b) The (necessary) particpants don't listen to the progress of others and add their input where it would be useful

In all, it's like pretty much any other methodology - it's only as useful as the particpants are able/willing to follow it. It is no silver bullet that will magically make your code better.

Isn't this just disempowerment by another name? (0)

Anonymous Coward | more than 8 years ago | (#14019979)

"Treadwell said. "We have realized inside Microsoft over the years that software practices we used in the mid-90s don't scale to the size of problems that we're tackling today."

You're tackling much smaller problems today than in the 80's and 90's. You already have all the base components, in the 90's all those had to be written. If you want to print things now, the OS handles it, no longer any need to write complete printer device drivers. Indexing algos? Already written, Sort? What type, all off the shelf. Need a lot of memory? No problem, no need to squeeze huge database access into 1Mb of ram these days, machines come with hundreds of MB, yet a sales order is still only 1k of data, the colour "red" is still 3 letters long.

In reality it's a damn site easier to develop software today than it was in the 80's and 90's. The JOB GOT SMALLER!

My view is these methodologies are just disempowerment. Before the team leader would call meetings when there was something to discuss, now with the methodologies he calls them based on some arbitrary rule, it disempowers him. They come with new naming conventions, because if you give a new name to an old concept you disempower the people who don't know the new name. They come with sparkly new procedures, before the team leader would choose an approach based on the problem, now he has to choose an approach according to the 'methodology' written without any knowledge of the problem he's tackling.

As a result, a huge complex product that was delivered by 10 people in the 80's and 90's now takes 5 times longer and 20 times as many people, and ends up 10 times the size with hundreds of times more bugs.

Shorter release cycle? (2, Interesting)

rayd75 (258138) | more than 8 years ago | (#14019984)

"Steve Ballmer, chief executive of Microsoft acknowledged during his keynote address at the Microsoft launch event that the company needed to get more agile and to produce software faster, to the tune of delivering technology every 18 to 24 months."

  No. No one wants such a short release cycle but you and your shareholders. If I may borrow one of your favorite words, there is not enough "innovation" in most of the technologies you purvey to justify an 18 month release cycle. You managed to pull it off for Windows XP and did nothing but piss off those of us who bought your line about Windows 2000. To us, it was clear that XP was nothing more than the finished version of Windows 2000. We had just spent a fortune on upgrading to the future only to be told 18 months later that we weren't worthy of free utilities, functionality upgrades, or even comprehensive service packs since we weren't on the latest release. As far as I'm concerned, you can keep your interim versions to yourself. Anything shorter than 3-4 years for operating systems and server products is lunacy.

the next big thing... (1)

SlashSquatch (928150) | more than 8 years ago | (#14020027)

...is no doubt the next MS software release. Guaranteed to eat up all your processes and space. Why do I need a pentium four and 160 gig hard drive in a system that is designed for "Word processing, Internet, E-mail, Spreadsheets, Other basic daily tasks"* ???

Oh yeah I forgot, I'm a screaming freaking retard.

"see you in HELL, candy boys."


why a new buzzword. (1)

fermion (181285) | more than 8 years ago | (#14020051)

One of the biggest problems in coding is the exponential increase in relationships as one adds staff, as described in the grandaddy of of development management books The Mythical Man Month

A second problem with code is avoiding the exponential growth of relatioships between data and the proliferation of rules that must be painstakingly reconciled. The is discussed in another grandaddy, Composite Structured Design

During the 90's many people, including MS did much work and wrote many books to explore solutions to these problems. Models that seperated data, controllers, and views. Models that isolated functionality into descrete well known funcions. Assertions that made sure inputs and outputs were within specification. Hiding data structure. I have written a significant amount of code using these techniques, code that seems to work well. The basis seems to be lmit the relationships in the system, and as a consequence the proliferation of knowledge.

I think that 40+ years of experience in computers has taught us this is the way to write good code. MS, Apple, IBM, all the big players work on this model to some degree. About the only new thing is tools to represent the entire system without intimate detail, and other tools to translate these representations into data types.

So this is what troubles me. Writing code is only a small part of the process. Defining boundries and interconnects, and bebugging, tend to the larger part. Once I know what the window manager will act like, I don't need to know anything else. The higher level code I write, the less I need to know and should know about the subsystems.

And I am not sure how XP fits into this. A group needs to meet to define functions and interconnects. Everything else should be handled through assertions and regression testing. We, as the engineers we want to emulate, need to code to the design. The problem seems to be that many are still living in a world where computer resources are limited, a world many never experienced. Or perhaps MS is just trying to keep an advantage by continuing to sacrifice speed over reliability. It might be useful to have meeting to gain authorization to link deeply into the subsystem, but hardly smart.

We use scrum, and it's working for us (2, Interesting)

DeadVulcan (182139) | more than 8 years ago | (#14020055)

But like any process, scrum won't work unless you have buy-in from every level. I think it took us almost a year before we really got into a groove with scrum and started getting really big benefits out of it.

Developers now work without meddling from management for at least the duration of a sprint (a month). We can focus and get lots of work done.

Transparency has built trust between the developers and the other stakeholders, like testers, usage experts, and management. There's far, far less tension between these groups. And whatever tension that does exist is kept off the shoulders of the developers.

We were a small company, bought out by a very large one, and now our group and our process is starting to be viewed as a model for other groups in the company to emulate, because we're (apparently) far more efficient, and we're getting a lot more work done.

We don't use XP (although we do have a lightweight code review process). The benefits of XP weren't quite as evident to us, so it's not something we mandate - developers can do it sometimes at their discretion.

Why quantity will never beat quality (1)

ardchoille (912260) | more than 8 years ago | (#14020076)

Well, maybe instead of rushing software out the door, they should be taking their time to ensure that their software passes higher quality control standards. One of the major reasons that the Microsoft Corporation is losing its users to other operating systems is that the quality of Microsoft products has greatly declined over the years. I have noticed more and more people and businesses switching from Microsoft Windows to Linux, which is a more stable and secure operating system, and that can only mean one thing: there are other operating systems out there which outperform Microsoft Windows operating systems. It's too bad that Microsoft seems to feel that quantity is more important than quality, I have a feeling that Microsoft is paying for it in the long run.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account