Weblogs Forum - Frequently Forgotten Fundamental Facts about Software Engineering

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Frequently Forgotten Fundamental Facts about Software Engineering

18 replies on 2 pages. Most recent reply: Nov 19, 2008 12:27 PM by nes

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 18 replies on 2 pages [ « | 1 2 ]

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 13, 2008 8:39 AM

> I posted a much more rude rant against agile methods at
> http://aflj.wordpress.com/2008/11/12/agile-development-is-m
> ostly-just-hype-imo/. If somebody thinks highjacking this
> thread has already gone too far, please bash me there (the
> tone of the post surely favours bashing, IMO).

I think you don’t understand agile in its historical context. From what I am sensing you have done iterative incremental development all your life and now when you read the agile manifesto you interpret it as something more extreme than what you are doing yourself to the point were it becomes nonsensical. What you and many people take for granted nowadays wasn’t accepted in many circles 15 years ago. You have to understand the agile manifesto against the backdrop of the traditional strictly sequential waterfall developments of the eighties and nineties with mammoth teams of 40 and more programmers.

Let me give you some examples on how you misinterpret:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” It doesn’t tell you what early and continuous means. Well let’s see and use two of the most extreme agile methodologies: XP (iterate every 2-4 weeks), Scrum (every 15-30 days). So are you telling me that showing the user some part of the system once a month is overly onerous and extreme? Compared to traditional waterfall where users often didn’t see anything for several years it might be. But I don’t believe one bit of your assertion that the user will resent you for showing him some progress on the application once a month. And your assertion that nothing of what you are showing works is nonsense too. I cite from the wikipedia on scrum:” During each sprint, a 15-30 day period (length decided by the team), the team creates an increment of potentially shippable (usable) software.”

“Simplicity–the art of maximizing the amount of work not done–is essential.” In some circles more documentation is better, so if we fill in 3 forms for every line of code we write we should be creating code at the speed of light right? and your assertion? “They were maximizing the work not done at the expense of testing”. Again I cite Kent Beck from wikipedia this time from XP: “The first time I was asked to lead a team, I asked them to do a little bit of the things I thought were sensible, like testing and reviews. The second time there was a lot more on the line. I thought, "Damn the torpedoes, at least this will make a good article," [and] asked the team to crank up all the knobs to 10 on the things I thought were essential and leave out everything else”.—Kent Beck. In many places developers don’t test and there is no review. Agile popularized testing and review and said forget about some of these other documents (flowcharts and what not). You can’t use the principle of simplicity to justify nullifying things that are important to agile methodology. That is just a perverse interpretation.

I could go on, but you get the idea. The article is just one big straw man fallacy. You misinterpret the principles in perverse ways and then complain that they don’t make any sense. Maybe you should read the stories of the people that signed the manifesto and what projects they managed and what they learned from those projects and what they are doing today to be able to interpret the manifesto correctly.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 13, 2008 6:50 PM

"P2. Good programmers are up to 30 times better than mediocre programmers, according to "individual differences" research. Given that their pay is never commensurate, they are the biggest bargains in the software field."

This is considered a "frequently forgotten" "fact"? I'd call it a frequently repeated conjecture.

We have no consensus on a comprehensive definition of programmer "goodness", so how can we measure it? Why is there so much variation in the claimed "better multiplier" (e.g. 10-100 times better) if the number is based on a scientifically valid study?

If there really are programmers who believe they are 30 times better than their colleagues, it might explain a lot about the problems of software product development.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 14, 2008 6:14 PM

> And they are the most cost-efficient industry I
> know about - what other industry lives off 5 to 7% profit?

I used to work for wholesaler. They had an overall 0.5% margin.

> I remember a very funny definition/comparison of
> efficiency/effectiveness. Say you need to climb on a wall,
> and you have a ladder. Climbing the ladder with the best
> possible speed is efficiency. Leaning the ladder against
> the right wall is effectiveness. It seems to me agile
> methods tend to maximize efficiency, but in a way that
> harms effectiveness. No matter how efficient you are, if
> you have to climb down and lean the ladder against a
> different wall several times, you aren't effective. Some
> lazy bum taking a moment to choose the right wall is
> surely going to get to the top of the right wall sooner
> than you. Even if you double your efficiency, it won't
> increase your effectiveness, unless you change your way of
> doing things.
>
> ...
>
> Why not try an agile process on spec and design
> documentation, before you start coding? Refactor it
> thoroughly, keep it minimalistic, provide many revisions
> of it to the customer for review, until the customer says
> it is OK. This is potentially a way of reducing the number
> of iterations - you are likely to have a usable and pretty
> stable spec after such a process, I think. With less
> effort than you would need to invest to actually
> implement all the revisions of the spec.

The point of getting something working early is to make sure you are climbing the right wall. Most of the effort put into 'big-upfront-design' is spent planning to climb the wrong wall. I think this where you are missing the point of Agile methods. Again, I'm not sold on everything that Agile proponents claim. But the idea of getting something up and running early makes perfect sense to me.

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Frequently Forgotten Fundamental Facts about Software Engineering

Posted: Nov 19, 2008 12:27 PM

Apropos Agile, here is an article from yesterday:

http://www.cio.com/article/464169/When_Agile_Projects_Go_Bad

Flat View: This topic has 18 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic


	Web Artima.com