Follow Slashdot stories on Twitter


Forgot your password?

Comment Re:Stupid (Score 1) 387

Global collaboration is a huge challenge that has not really been solved. Or, more accurately the solutions are still not as good as being in person. But, presumably some one made the cost benefit decision that the advantages of being global make up for the disadvantages. (skeptical undertones intended)

From a classroom perspective and any situation where you can get a bunch of people together to solve hard problems, vast amounts of whiteboard space are a highly effective tool. The problem is after spending a bunch of time going down bunny trails, back tracking, etc... which the white board is really good for, the final result needs to be put into a form that can be made persistent in some way. For something short term that will be used immediately, a photo might be good enough to refresh memories, when necessary. For something to be kept longer some one gets the thankless task of transcribing the results. Although, I thank that person profusely for doing something incredibly important but tedious.

Comment Re:No. (Score 1) 507

Of course you would say that. You would still be wrong. What you call "organizational dysfunctions" -- but everyone else would call "a normal mix of people" -- can be handled more effectively under a waterfall-like process than under an Agile one.

Well, that is the Taylor versus Deming argument. Very loosely summarized as: People are the problem versus people are the solution. That is more fundamental than Waterfall versus Agile. It seems like it is what drives people to one process or the other.

Agile is likely to be less efficient because you start lots of developers writing code before anyone has a good grip on what the project should look like

It has not been my experience that you start with developers writing lots of code before understanding the project. You have to fill the backlog before doing anything. That means prioritizing backlog items which means knowing enough about those items to gain some prioritization. Although one trap is de-prioritizing really valuable things that you don't are risky rather than doing the opposite which it prioritize efforts to resolve that risk in some way. The shorter the sprints means the smaller the backlog item needs to be to fit in a sprint which means a fairly high degree of understanding of requirement and design in order to split stories small enough. The only significant difference with respect to waterfall then is that the best splitting and understanding of requirements and design is on near term items and later items are more vague.

I can write a whole bunch of other stuff because there are consequences to every choice and those consequences are handled using different techniques. And, on top of the general consequences, every organization is a complex system with many hidden and visible feedback loop and both waterfall and agile interact with that system good, bad, and sideways. Change from one to the other and all of those feedback loops kick in and new ones are created and the whole system can react in unexpected ways. This is nothing new, Six Sigma, TQM, Lean, and others I have never heard of get brought into organizations and perturb the system in unexpected ways.

Comment Re:No. (Score 1) 507

Well, the systems engineer creates great requirements that exactly match the customer's needs at that time and then just as development starts the business environment changes and those requirements are no longer valid. If you are following the do ALL the requirements, followed by ALL the design, followed by ALL the development, etc... What has happened is you have detailed requirements and design and done a ton of work that created zero value to anyone. Presuming you make the rational decision to abandon the no longer relevant requirements. Should you push through and develop software to those requirements it probably creates even more waste.

The thing is Waterfall versus Agile is not really the argument. We are just rehashing the Taylor (Scientific Management) versus Deming (Lean) argument. The thought experiment I do is to think of a Lean organization that is currently doing waterfall. Applying Lean to the waterfall process over the course of much continuous improvement starts to look like agile+continuous delivery.

Consider the wastes of Work in Progress (WIP) and Handoffs. The first thing one would notice is that the requirements phase creates a big queue of Work in Progress (WIP) in the form of unimplemented requirements for the Design phase which creates a queue of unimplemented designs for development and so on... Queues kill cycle time and WIP is waste. So, you put in WIP limits which means less work to complete which creates faster cycles that start to look a lot like sprints. That will tend to expose the waste of hand off because the overhead of hand off gets exposed by the higher cycle time. So, you pull your Analysts, Product Owners/Customers, developers, testers closer together to reduce the handoffs between them which at its ultimate conclusion starts to look like an Agile team. I could keep going, but I think that describes the idea.

There are a variety of other ways to look at the differences. There is the people are the problem and more process and control is the solution to problems (Taylorist) versus people are the solution and making the people better is the solution. (Deming)

If you are in a Taylorist organization with no desire to change I would not attempt Agile. But, there are lots of good software development practices that have the Agile sheen on them that work in any framework.

Comment Re:No. (Score 1) 507

Well, I would not consider hiding dysfunction a good thing. Successful waterfall tends to meet the schedule and budget and fail at providing what the customer actually wanted because customers generally don't know or can't describe what they really want until the see it.

But, setting that aside. Waterfall is fragile to change. Agile is resilient to change but will expose a lack of discipline in other areas. But, there are two fundamentals that change that fragility to resilience. The first is that short iterations exposes problems quickly. Second, that continuous improvement is embraced to correct the top problems exposed every iteration. So, "fail fast" and correct the problem. Pretty much every other practice involves ways to fail faster or correct typical failures. And, some may not work within your organization, if it doesn't you find out quickly and try something else.

This is a huge weakness of the waterfall process. It typically takes a long time to get through the whole process 6 months to years. So, you can't tell if you got the requirements phase right until quite a long time after going through that phase and you don't get to correct it until the next project and assuming there is a correction it is often more process for the sake of process.

In an Agile iteration you cycle through a significant chunk of the process, and try to do a production deployment of something in as few iterations as possible to expose all the problems. And, especially when switching an existing application development to an Agile process, you are not going to get everything into the iteration all at once. Make sure you are honest and accept that you don't have fully automated end to end integration test, yet and set aside an iteration to do that and correct any problems before deploying.

I will tell you a little secret. Every time my group has made a significant change towards being more "Agile" we have generally had some fairly significant problems in the first sprint. What some might even call a failed sprint. But, we take our hits and figure out what needs to be fixed and the second sprint is generally successful, and 3 and 4 are better and better.

One could argue that waterfall is good at the extremes. Perfect organizations where everything it locked down which makes the process work, and horrible organizations where the process rigidity provides the discipline that would not otherwise exist. Agile works better in that space in the middle where people are generally good and trying to do the right thing, and you just need a framework for discovery. Whether that discovery is of the customer's real needs or internal development problems or whatever...

Comment Re:No. (Score 2) 507

Or, as I put is in a longer post. Agile practice have a tendency to expose all of the dysfunctions and waste. The analogy is that a deep slow moving river hides even the big rocks. Agile lowers the water level and starts exposing all the rocks, and the point of having short iterations and retrospectives is to recognize the rocks and remove them. Summarized as "Go slower to go faster." But, management decides not to invest in removing the rocks because the software has to be done on schedule, but reality is all the bombs that are going to cause the schedule to be missed are left behind.

Comment Re:No. (Score 4, Insightful) 507

That is exactly what happens. And, some of the leaders in the field have realized that a lot of what is called Agile (Poppendiek, Larman, Vodde, Leffingwell) are essentially implementations of Lean Product Development from Toyota to Software Development. What often happens is that, like Lean in manufacturing, organizations take up some of the forms of Lean/Agile while completely missing the fundamentals and the culture. That is key. If you don't realize that Agile or Lean are an organizational culture change not a set of practices that are a silver bullet what you end up doing is slapping Lean or Agile onto a dysfunctional culture. And, one of the things that many Agile practices will expose very quickly is all of the dysfunctions and waste built into an organization.

Consider the poster who complained about QA/QC being ignored. What was happening in waterfall was the exact same thing, but the long QA/QC cycle was hiding the fact that the developers were producing crap. Actually, calling it QA/QC was a misnomer, it was actually finish all the stuff we half-assed during the development phase. Oh and what management thought they would get from Agile was that they could knock out QA/QC and get the same work done in the same time that would have been allocated for the development phase in waterfall. So, the same schedule pressures that forced developers to take short cuts in waterfall never went away, and the result is that the same shortcuts happened without the QA/QC phase to fix them. And, was there a retrospective or root cause analysis or empowerment of individuals to pull the stop cord on the train to correct these issues that were exposed. Of course not because if you stop you will miss the schedule and that cannot happen, etc.. etc... Slapping Agile practices onto a dysfunctional organization does not fix the dysfunction. Culture changes take years, especially in larger organizations when there is not the top to bottom commitment to changing the entire organization.

There is also the problem of "flexible" translating to "without discipline". My experience is that Agile and Lean requires a level of discipline far beyond typical waterfall. The waterfall processes often require the facade of discipline, but rarely actual discipline especially at the individual level. And, when discipline is attempted on individuals it usually has more to do with imposing additional process and reporting that does not contribute to actually delivering results. Which is exactly the same thing another poster complains about where Agile gets used to micro-manage daily tasks. Which is another example of missing the point, daily tasks and a daily meeting is to free PMs and Managers from micro-managing holding each person accountable for accomplishing something each day. I call it peer pressure accountability because other than sociopaths most people don't want to be the guy who tells their team mates that they did not do what they said they would do yesterday, or did some ridiculously trivial task while some one else did something significant.

In some cases Agile shouldn't be used, but those are generally caused by external forces like being in an inflexible contract situation. In that case, I advise the philosophy of "Don't lie to yourself." Instead understand your constraints and realize a lot of the practices used by Agile and Lean organizations are almost universally beneficial. Automated testing and continuous integration are a good idea regardless. Splitting work into small chunks and working on a cadence (takt time) can be beneficial locally even though globally you are still producing tons of WIP. And, so on and so forth...

Comment Re:And why is bitcoin different? (Score 2) 253

but remember that we originaly got the loans paying huge interests, so the private entities giving us the loans had huge profits for DECADES (no one had any complaint!).

And, the "bail out" loans did not really go to running the Greek government or Greek people, it went to bailing out the banks that used to hold greek sovereign debt. Currently, Greek debt is essentially held by the IMF and ECB. Much like in every other country banks do not suffer the consequences of the bad loans they make, but instead privatize the profits and socialize the losses.

Comment Re:Stupid is as stupid publishes.... (Score 3, Informative) 486

It is even worse than that. They are using a BufferedWriter for the so called writing to disk portion. So, they are actually comparing the worst possible way to append a String in memory to appending bytes to a bytes buffer and periodically writing that to disk. So, basically comparing two different in memory string appending techniques? When you bring the OS into play it is even less likely to actually show anything having to do with the disk because the OS will write asynchronously.

My grade: F- and they should be mocked mercilessly until the paper is retracted for being idiotic.

Comment Re:"Light drag?" (Score 2) 231

This does happen, although I am not sure if it is seen in red shifts. It is definitely seen in the Cosmic Microwave Background where large cold spots are thought to be due to voids along the line of sight that the CMB photon traveled. I presume a similar effect would apply to any photon crossing that void.

Comment Re:Since when did unknown == paradox?? (Score 5, Informative) 231

Paradox - "a statement or proposition that, despite sound (or apparently sound) reasoning from acceptable premises, leads to a conclusion that seems senseless, logically unacceptable, or self-contradictory."

The paradox is that energy is supposed to be conserved, but space has energy and is increasing. So, we have a logically unacceptable a conclusion.

Just because it is a current paradox doesn't mean it can never be resolved. We find an energy source, or figure out the laws of physics which in this case allow for the creation of energy and is stops being a paradox.

Quantum physics calculations say the vacuum energy is one value while measurements of the curvature of the universe say it is a different value. That is a paradox especially when both Quantum physics and the physics involved in measuring the curvature of the universe seem to both be right in other respects such that making changes to resolve this paradox causes them to stop describing other things accurately. So, we have logically unacceptable conclusion.

The red shift thing doesn't look like a paradox, but a really cool test of our understanding of cosmological red shift.

And, the homogeneity problem could be a paradox linearity of expansion says the universe is homogenous, observations say it is not. But, they don't mention whether observations have done a reasonable job of determining the dark matter distribution of the universe.

There are paradoxes in the article, but it does drift into one topic that is not a paradox and another that is borderline.

Slashdot Top Deals

To communicate is the beginning of understanding. -- AT&T