aspose file tools*
The moose likes Agile and Other Processes and the fly likes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark ""Boy Scout" Software Engineering Principles and Do-or-Die projects " Watch ""Boy Scout" Software Engineering Principles and Do-or-Die projects " New topic
Author

"Boy Scout" Software Engineering Principles and Do-or-Die projects

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Imagine a project whose schedule is so compressed, and/or whose budget, or team size is so constrained, that the only "obvious" way to succeed is to work 16 hours a day, 7 days a week, with no vacations until the project is finished.
Such projects may also be using some of the concepts of the popular "extreme programming" (XP) approach including the technical activities of design (e.g., refactoring), coding, and testing.
"Boy Scout " principles that lead to high levels of software quality and easily maintainable systems, but can be counter-productive and even fatal in high-pressure "do-or-die" projects.
If your manager comes at you with this argument, would you hang on to your principles and run or down tools and surrender.Organisational politics can be a dirty business. It's one way of finding out who your loyal friends are.
Different POVs welcome.Feel free to move this thread to another forum.
regards
[ August 15, 2003: Message edited by: HS Thomas ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by HS Thomas:
Imagine a project whose schedule is so compressed, and/or whose budget, or team size is so constrained, that the only "obvious" way to succeed is to work 16 hours a day, 7 days a week, with no vacations until the project is finished.

A Death March: http://www.amazon.com/exec/obidos/tg/detail/-/0130146595/
Such projects may also be using some of the concepts of the popular "extreme programming" (XP) approach including the technical activities of design (e.g., refactoring), coding, and testing.
"Boy Scout " principles that lead to high levels of software quality and easily maintainable systems, but can be counter-productive and even fatal in high-pressure "do-or-die" projects.

I don't follow you here. Can you give an example of such a principle?
If your manager comes at you with this argument, would you hang on to your principles and run or down tools and surrender.

If I decided not to run, I'd still want to use all the tools which I think would help me survive the project.
Organisational politics can be a dirty business. It's one way of finding out who your loyal friends are.

Are you suggesting that someone is doing a Death March just to find out about loyality?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4456
    
    6

Does this mean that in the "do-or-die" situation, the manager is asking that everything must be coding? No testing or refactoring? Just jam code in, copy/cut and paste, etc.?
I feel for you and I know the pain and frustration.
When I get this kind of pressure put on me I usually push back though. Regarding the hours, well there's really not much I can do about it--I'll work as hard and as long as everybody else on the team is willing to work. But regarding quality, I'll always argue that trying to cut corners on quality only creates more problems that make the schedule pressure worse. That's not to say that I won't compromise sometimes but I'll definitely try not to produce code that's blatantly sloppy. At the very least, it should be amenable to refactoring at a later time.


Junilu - [How to Ask Questions] [How to Answer Questions]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Can you give me an example of such a principle

No, I cannot give you a single example.
But here's the Boy Scout's Motto :

The Scout Motto is BE PREPARED, which means you are always in a state of readiness of mind and body to do your DUTY.
Be Prepared in Mind by disciplining yourself to be obedient to every order, and also by thinking out beforehand any accident or situation that might occur. Develop the habit of asking yourself "What could possibly go wrong in this situation?" so that you know the right thing to do at the right moment.
Be Prepared in Body by making yourself strong and active and able to do the right thing at the right moment, then do it.

Now doesn't that sound familiar ! Do the right thing at the right time...Do your DUTY...What could possibly go wrong in this situation? (Let us write a test).
But would you take these Boy Scouts into War, without preparing them further. A War where the rules are unknown. The mission is such that a BURST of activity / energy is required and there are going to be casualties. If a leader doesn't get that loyalty he/she is the first casualty.
Are you suggesting that someone is doing a Death March just to find out about loyality?

Umm. Yes! The Death March was always a certainty! The Outcome is not!
The one demanding the loyalty may well be the first casualty.
regards
[ August 15, 2003: Message edited by: HS Thomas ]
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

The Death March was always a certainty! The Outcome is not!

By definition, the outcome of a "death march" is failure. You can deliver nothing, in which case you've failed the customer, or you can deliver poor-quality software, in which case you've failed yourself. Either way, it's failure.


[Jess in Action][AskingGoodQuestions]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Does this mean that in the "do-or-die" situation, the manager is asking that everything must be coding? No testing or refactoring? Just jam code in, copy/cut and paste, etc.?

The manager doesn't care how it's done but just wants to deliver a reasonably good product in a short time-to-market frame. He doesn't even know whether there will be a project at the end of that time. The opportunity in the market may have disappeared.
What is the best thing that can happen ? You still have a project at the end of the time and a small flickering market.
What is the worst thing that can happen ? You are all dead-meat at the end of the Mission.
Another best thing that could happen was that some of the best work might be produced under pressure if there are the right people on the project, but no one knows that yet.
[BTW Ernest I borrowed the term Death March from the link Illja posted but did not mean that the outcome was definitely Death but that it could be.]
regards
[ August 15, 2003: Message edited by: HS Thomas ]
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Looks like everyone beat me too it, but I think Death March is a must read for every software engineer!
I would not say that every death march is a failure. At startups, this is the norm early on. When we hired people at my last startup, we made it clear that we were an early startup and 60+ hour weeks were the norm. In exchange we gave people good stock options. The company is still around, despite the economy.
As for surrendering your principles, the answer is, it depends. Principles are great to have--until they get in the way. If your principles aren't conducive to meeting your needs, then you should consider changing them. (The caveat is, what are your true needs, often times short term needs conflict with long term needs.)
--Mark
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
When we hired people at my last startup, we made it clear that we were an early startup and 60+ hour weeks were the norm.

Do you think you'd all have had a much better product if you all were doing 40 hour weeks? Or did stretching your staff rather than time prove miraculous ?
Would you repeat some of the things you did at that start-up on a normal project ? If so, what and why ?
regards
[ August 15, 2003: Message edited by: HS Thomas ]
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
Originally posted by HS Thomas:

Do you think you'd all have had a much better product if you all were doing 40 hour weeks? Or did stretching your staff rather than time prove miraculous?

It was moot. When I joined, the parameters had been set (scope and deadline). They weren't 100% fixed, but weren't going to change by 50% either. I could've choosen not to work for them. Instead I felt that the opportunity, despite the long hours would be worthwhile, in comparisons to other opportunities available (this was late 99, so there were many).
I could naively say the product would've been better if we had 40 hour weeks. However, maybe under that time schedule, we might not have even gotten funding in the first place.
Originally posted by HS Thomas:

Would you repeat some of the things you did at that start-up on a normal project ? If so, what and why ?

That's a really big question. I could fill a book with my response--and I have! It was experiences at my last startup which help crystalize the ideas which became my book. In fact, the first example in the opening pages talk about the issue of scheduling at this company.

--Mark
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Well ,will just have to wait till the book surfaces then.
It seems , once the time factor is messed around with , the other principles soon follow suit and go out the window.
I must make it clear, when I use the term "Boy Scout" principles I did not decry Agile / XP principles.
A Boy Scout might be co-erced into doing some overtime.
A well-seasoned XP /Agile Team may well be better prepared for such a Mission and consequently much better organised.
So the term "Boy Scout" was used for XP/Agile wannabes faced with a tough decision to ditch said fledgling principles that they may be in the process of adopting.

I'd go with Illja's and Junilu's advice with doing as much as you can within the time , fully expecting to cover the ground again. I think XP allows for this.
regards
[ August 16, 2003: Message edited by: HS Thomas ]
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
but can be counter-productive and even fatal in high-pressure "do-or-die" projects.

At the same time there is a perception by managers of such projects that such principles are a risk. Funnily enough, the author of the Death March Ed Yourdon, has some writings on this.
I'll see if I can find it again.It was actually him who used the term "Boy Scout" principles. I can't say I took to his other term - "grunts" in the trenches.
Much of the material from the seminar Ed Yourdon's Extreme Project Management Seminar is drawn from Ed's new book, Managing High-Intensity Internet Projects (Prentice-Hall, 2001), and is an update and refinement of principles that he documented in his best-selling book, Death March: The Software Developer's Guide to Mission-Impossible Projects (Prentice-Hall, 1997).

If someone can work out which principles are risky for such projects, I'd be glad to know too.
Extract from Managing High-Intensity Internet Projects
regards
[ August 15, 2003: Message edited by: HS Thomas ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: "Boy Scout" Software Engineering Principles and Do-or-Die projects