Become a fan of Slashdot on Facebook


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Way ahead of ourselves (Score 1) 448

Remember the "paperless" office, how computers were supposed to eliminate paper? Yeah right! Sure, there are some paperless offices, but that is not the norm. Most offices go through more paper now than they ever did. That paperless office was supposed to be a reality back in the 90's. So much for that!

The role of paper has changed. It used to be the primary, permanent storage medium for information. Now it's more of a temporary medium to store text while it's in process. After the process is complete, the paper is often destroyed. Still, paper hasn't gone away.

Similarly, it's going to take much longer than anyone anticipates, to replace office workers with automation. And similarly, the role of office workers will change, and might even grow.

Comment Re:Agile (Score 1) 332

There is nothing in Agile that restricts creativity and choice by programmers. What it does is allow programmers to make technical design choices, and product owners to make business-facing choices. The business people decide what they want it to do, programmers decide how to get it done.

If anything, it's the waterfall process that allows "architects" to make all the design choices for the programmers, who are expected to just follow the requirements like a code monkey.

Comment Re:Agile (Score 1) 332

You are certainly correct that the people are more important than the process. Funny, that's the #1 value on the Agile Manifesto!

Well, I don't want to cherry pick too much. So here are some more shops that use Agile:

Toyota, Cisco, Phillips, Intuit, Honeywell, Ericsson, Amazon, Google, LinkedIn, SalesForce.

Still not enough? This HP survey found that 69% of development shops now are pure agile or "leaning" agile.

Comment Re: Agile is good for some teams & projects, h (Score 1) 332

In my 27 years in software development, I've never worked on an Agile project that failed to deliver finished products. In agile, the initial coding becomes part of the analysis and design phase. Agile does not mean less (or inferior) design and analysis. It just changes the method and sequence.

Every waterfall project also has technical debt and design errors. That is not specific to agile. In fact, because waterfall attempts to complete the design without anything concrete (i.e., working) for customers to see, it becomes much easier for bad designs to become buried in the reams of documentation.

Comment Re:Agile (Score 1) 332

Yes, yes, yes, yes, and yes. Most of my career has been in small shops, ranging from 1 to 14 developers. All of them used agile, and succeeded because of it.

There are badly planned agile projects, but this is not a feature of agile. There are also badly planned waterfall projects, but this is not a feature of waterfall. The notion that agile means "lack of planning" stems from a lack of understanding of what agile really is. Agile is a different way of organizing priorities, and it does so in a different sequence than waterfall. It does not eliminate organizing or planning or priorities.

Toyota, SalesForce, Amazon, Google, Intuit, and many other major corporations use agile successfully, against stiff competition.

Comment Re:Agile (Score 1) 332

If your agile shop lets the product manager / customer get off the hook without defining what they want, they are doing it wrong. Agile does not remove the need for requirements, it only changes how and when they are created. Up front, only the big outline is created, and the individual points are fleshed out as you get to them. This is NOT the same thing as getting off the hook.

Comment Re:Agile (Score 1) 332

I have worked in a number of Agile shops with competent, enthusiastic professionals. I'm sorry that you have had a less positive experience.

To be competent, it is not a requirement that you also be "senior." I sit next to a kid just one year out of college, who definitely meets the definition of "competent." Inexperienced, yes, but also competent.

Comment Re:Agile (Score 1) 332

Open source projects are not ideally suited to Agile, because one of the core features of most Agile processes is having teams that are physically located together. For most open source projects, this is not practical.

Agile is not the ONLY methodology that works, so I'm not surprised that Linux succeeds without Agile. However, many large corporations use Agile methodologies in a big way: Cisco, Phillips, Intuit, Honeywell, Ericsson, Amazon, Google, LinkedIn, SalesForce, just to name a few. At least some of these corporations produce software that is "very good."

Comment Re:Agile is good for some teams & projects, ho (Score 2) 332

Exactly! So when waterfall tries to nail down the details up front, it does itself a disservice. Users find out months later that those nailed-down details don't quite work for them, and now you have to go back and re-engineer your project. With Agile, you find out much earlier in the process that the details weren't right.

Comment Re:Agile is good for some teams & projects, ho (Score 1) 332

We agree about the importance of well-designed code. Poorly designed code hampers agile development as much as it does waterfall development.

My comments were about the requirements. Waterfall pretends to know the requirements up front, but then has to follow the project with a series of change orders. This happens because users often don't really know what they want until they see something in action. "Yes, this is good, but..." Because the change requests can't happen until the project is complete, they are relatively expensive to implement, especially if the changes affect the underlying architecture.

Agile assumes that these change requests will happen, and focuses on reducing the cost of the change requests. By getting software into the hands of "customers" very early in the process, these changes are found much earlier in the process, when it's relatively cheap to change the architecture, if needed.

There is a reason that waterfall timelines are measured in quarters or years, while agile timelines are typically measured in terms of days or weeks.

There is no inherent quality difference between Agile and Waterfall, in my experience. The difference is in how the project is broken down into small pieces, and in what order those pieces are carried out.

Comment Re:Agile is good for some teams & projects, ho (Score 0) 332

Agile doesn't say you can't have big goals, only that the details can't be fully known up front.

I wager that on every single waterfall project you have worked on, there have been numerous change requests after the project was supposed to be "done." If it was a big project, I wager there were many change requests. In other words, the original requirements turned out to be fiction. The true requirements were not really known when the project started. The product owners thought they knew the requirements, but when the gears started to turn in production, they found that their original design was flawed, and had to be revised.

Agile accepts this reality up front, and does not attempt to fill in every detail at the beginning. It therefore eliminates a lot of work that would otherwise be thrown away during the waterfall revision process. Agile recognizes that fixing flaws becomes much more costly, when they are found later in the process. Waterfall does not do this, resulting in expensive change requests at the end of the process.

Slashdot Top Deals

"A car is just a big purse on wheels." -- Johanna Reynolds