Searching \ for '[TECH] Agile programming' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Agile programming'.

Exact match. Not showing close matches.
PICList Thread
'[TECH] Agile programming'
2009\01\30@091317 by olin piclist

face picon face
Jake Anderson wrote:
> Anybody have any thoughts on "margin" as it applies to software?

It's usually pretty good.  The hosting and bandwidth costs amortized over a
bunch of customer downloads is probably just pennies, but you can sell it
for 10s or even 100s of $$.  Bridges don't have anywhere near those kind of
margins.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\01\30@095124 by Alan B. Pearce

face picon face
>> Anybody have any thoughts on "margin" as it applies
>> to software?
>
>It's usually pretty good.  The hosting and bandwidth costs
>amortized over a bunch of customer downloads is probably just
>pennies, but you can sell it for 10s or even 100s of $$.
>Bridges don't have anywhere near those kind of margins.

<VBG> Somehow I don't think that is the kind of margin he means ...

When I read the OP post, I had a thought about it, and the programming
equivalent of 'engineering margins' that would be used for verifying load
bearing on structures, is surely program structure and planning. Keeping
programs modular, easily verified, use of Lint type tools, program path
validation, limit checking, etc is the programmers correspondence to
ensuring load bearing capability on a mechanical item.

The term 'margin' doesn't really come into it, unless you think in terms of
maximum numbers you are likely to encounter (both positive and negative) and
ensure that value fields are in an appropriate format and contain a suitable
number of bits, and that the arithmetical routines can calculate with
sufficient accuracy to maintain the end calculation accuracy required. This
may also require an assessment of the order of calculation (as per the
recent discussion on calculator algorithms) so that accuracy is maintained.

On reading over the above I guess items like ensuring that the processor is
fast enough to complete the algorithm in a require time (I am thinking
embedded closed loop control) requires a worst case speed margin as well.

2009\01\30@101121 by Vitaliy

flavicon
face
"Nate Duehr" wrote:
> There's at least one software business owner who wholeheartedly
> disagrees with the "bullpen" approach.  Have you read "Joel on
> Software"?

Yes, I've read his article, and in fact most other articles (even bought the
book). He's actually quoting Peopleware, where they argue that every
programmer must have his own "quiet" place because it takes time to get "in
the zone". Their pet peeve is PA, however -- they describe how in some
organizations the programmers would dutifully lift up their heads from their
cubicles to listen to every PA announcement.

To put it simply, I think both Joel and Peopleware are wrong on this one. If
you're working on a collaborative project, you've got to collaborate.
Agilists recommend balancing the openness and accessibility of the bullpen
approach with the privacy of cubicles. I imagine a large room, with cubicles
along the wall, and a wall that doesn't have cubicles along its length, with
a large whiteboard/"information radiators" for impromptu meetings.

We don't have this sort of environment at work, but we do communicate a lot.
The doors are always open, and there is an understanding that anyone is free
to come in and interrupt what I'm doing if they need my help, and I do the
same to other people. Seems to work OK.

BTW, Joel and I must have read a lot of the same books. :) His "how many
piano players are there ..." example from "The Guerilla Guide to
Interviewing" is straight from the "How to Hire Top Performers" book.


> I'm in "tech support" and since about 1994 have worked in "bullpen"
> environments.  I've adapted, but I dislike them.

A long time ago, I worked in tech support for a very short time
(Getronics -- maybe you've heard of them?). *Shudder*


> I'm not as productive listening to all the crap that's not my
> responsibility going on around me, so I've developed a very good
> ability to ignore everything.  Sometimes when co-workers walk up and
> just want to chat, they marvel at the fact that I don't even know (nor
> care) that they're behind me, even if they address me.   My DSP filter
> in my brain keeps them below consciousness level unless it senses that
> they are asking something work related.  It also perks me up if I hear
> similar bugs/problems to new ones I'm working coming from a nearby desk.

The software development environment is a lot different from the tech
support environment, in that you don't have customers calling you
constantly. So I imagine it would be fairly quiet, most of the time.


> But otherwise, I'd rather have a closed door and quiet.  I'd be more
> productive.  I'm ALWAYS more productive when weather or other
> circumstances have me working from (a quiet) home.

I find that I'm most productive alone, at night. It doesn't matter whether
I'm home or at work, except for the fact that at work I have access to all
necessary equipment, and a much better computer. :)


> (If my wife's
> home, my productivity goes in the toilet, unless I excuse myself and
> go to another room on another floor of the house.)

:)


> Interestingly, I started noticing how often the modular furniture is
> re-arranged and talked a bit with the facilities people about how much
> that costs to bring in electricians, re-wire the data cabling, etc.
> Not long after, I read an article that debunked the myth that modular
> furniture is "cheaper", since managers always seem to want to re-
> arrange it every year or so.  Drywall and doors and a floor plan that
> doesn't move, is actually cheaper in the long run.  I then talked
> about this with facilities and they agreed... no moves/changes would
> have saved our company tens of thousands a year...

Modular furniture is crazily expensive. Something like $5k per cubicle, it
is insane -- building a 10' wall costs about half as much. It has its uses,
however.


> The last time we had to move the modular furniture, they made it
> taller -- now we regularly see people doing dangerous and stupid
> things to talk to co-workers on the other side.  I just dial their
> extension and if they don't answer, leave a message.

We got our cubicles for free, and they're the tall variety (6'). If I had a
choice, we'd buy the shorter 4' ones. Also, after three moves and six years
in business, I think we finally figured out the perfect arrangement for an
engineering or software company, it is a short bullpen surrounded by offices
and conference rooms. We somewhat approached this ideal with our current
office, but the open space is not rectangular enough, and lots of it goes to
waste. Windows and skylights would be a nice touch. :)


> The most AWESOME piece of equipment I have is my wireless headset.  We
> all have them, they don't seem to ever interfere with one another,
> they cost over $300 a pop, and they're the best thing for a tech
> support team since sliced bread.  I will probably buy my own for work,
> if I ever leave the company, it's that useful.   Any tech support
> manager who balks when their staff asks for them because of the cost,
> should have their head examined.  I'd rather have a slower PC, or any
> number of other things taken away, before I would drop the cordless
> headset from GNI Netcom.

Hm, I think my headset cost around $150. It's about the size of a normal
Bluetooth headset, has a range of about 30', and it came with the "lifter"
that lets you pick up the receiver remotely. I'll post the
manufacturer/model number tomorrow (lest I forget :).

Vitaliy

2009\01\30@133125 by olin piclist

face picon face
Vitaliy wrote:
> "Nate Duehr" wrote:
>> There's at least one software business owner who wholeheartedly
>> disagrees with the "bullpen" approach.  Have you read "Joel on
>> Software"?
>
> Yes, I've read his article, and in fact most other articles (even
> bought the book). He's actually quoting Peopleware, where they argue
> that every programmer must have his own "quiet" place because it takes
> time to get "in the zone".

I've worked in a variety of configurations, from open area with desks and no
partitions, to a bullpen with 4 engineers bounded by tall partitions, to a
private office with a door I could close when I wanted to (although I left
it open 99% of the time).  Each has their advantages and disadvantages.

My first job out of school was the open area with desks.  That was very
useful to me as I happen to end up next to the division guru, and I could
listen in on people coming by and asking him questions and his answers.  I
could also easily ask him questions, often followups on answers he gave to
others after they left.  I was careful not to abuse this, and ended up
learning a lot of practical stuff you can't possibly learn in school.  It
was a great experience.

My second job was the bullpen.  I was closely collaborating with the guy
next to me, and it was definitely beneficial to just talk to him as needed
as apposed to having to get up and go to another office, and then possibly
finding he's not in at the moment.  It was also useful more often than you
might think to overhear technical conversations between others and jump in
with a perspective they weren't thinking about and that wouldn't have
occurred to them to ask about.  That worked in reverse sometimes too.  The
gotcha is that everyone has to have a certain etiquette about keeping
gratuitous noise and chit-chat to a minimum.  For the four of us in that
company at that time on those projects I think it worked well, and I'm sure
separate offices would not have been as effective.

In my third job I had the closed office.  Yes it was nice to have quiet when
I wanted it.  Others talking around me really breaks my concentration.
However, I still think it was not as effective as the bullpen environment,
at least for me.  I felt less connected to what was going on outside my
immediate project.  I'm the kind of guy that likes to understand the big
picture and even the technical details of areas I'm not immediately working
on.  And even though I say so myself, I'm good at watching over the big
picture technically and spotting incompatibilities and other issues before
they become problems.  It's hard for me to do that, and a little frustrating
for me, when I can't tune in to some level of project-related chit-chat
outside my official scope.  Other people just want to get their specific job
done, and are most effective if you let them focus on it and not distract
them with "irrelevant" details.  For them a private office is probably best.

So in summary, I think there is no single right answer.  The optimal type of
environment has a lot to do with the individual people and somewhat with the
nature of the project and the amount of collaboration needed.  The only rule
is that there is no rule.  Good managers learn the peculiarities,
preferences, abilities, etc of each individual and cater the environment and
responsibilities accordingly.  Of course physical space, budget, and other
necessities means you can't satisfy all of these for everyone
simultaneously.  All you can do is try to accomodate as you can.  However,
fast rules like "no closed offices" or "bullpens only" are a bad idea.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\01\30@182926 by Nate Duehr

face
flavicon
face
Oooh, received all of your message, and had no new comments, except on this
one.

You hit one of my pet peeves.  When my company can't seem to afford to keep
my desktop/laptop/whatever machine at LEAST as fast as my 3 year old home
PC, I get grumpy.

Never once have I had as big a monitor (or dual-monitors, or more) at the
office.  It helps me tremendously at home.  (Ticket system up on one
monitor, maximized, e-mail and any pending replies I'm working on for
customers,  on the other.  Terminal window or troubleshooting documentation
up over the top of those.  Very little clicking to switch focus from looking
at the customer's system to typing the response, or updating the ticket.)
Far too many companies don't "get it" here.  (The Joel on Software guy's
insistence that everyone have at least one 30" monitor with very high
resolutions would also cover it...)

When I worked less directly with customers in a sysadmin role, from home --
one monitor always had the system monitoring tool up on it, and the VPN was
always connected.  It saved countless minutes when the pager went off, to
just pop downstairs and look for the thing highlighted in Red, pop another
window, fix it, and go back to whatever I was doing.  A note to self to
script or otherwise automate that recovery process, or add a monitor if it
was something unmonitored, meant that the system always got better over
time.  At the office, I had a dinky 17" CRT, and everything was just
slower... still the same applications running, but all piled on top of one
another.  Eventually we put some of the monitoring stuff up on a wall and I
built some "what's going on?" scripts that would go out and query critical
processes from 18 different sites in a single window for myself, but
still...

Pet peeve.  Not having enough monitor real-estate these days, is stupid.
Not having dual monitors, is like having a teeny tiny cramped student-sized
desk to work from with real papers.  Not adequate anymore.

Right now, I have an medium-oldish IBM T43 laptop, docking station, and a
Dell 19" non-widescreen LCD hooked to it.  It does "dual monitor" between
the Dell and the laptop LCD.  I'd prefer bigger on both and higher
resolution, but this kinda works... home is far better.

I run computers for a long time before upgrading them, and when I'm a few
years behind "state of the art" at home, and the work machine is lagging
behind that in significant ways, I get pretty grumpy.  Basically, I want the
system to be responsive when doing at least two tasks back and forth at a
time and enough screen real-estate to watch both things.

In the past, we had to do this with multiple machines at one's desk, and
I've done that... but the fan noise and constantly kicking things under the
desk because you've got three "beige boxes" under there, gets old.  The
"interrupt" to switch mice and keyboards isn't very productive either, but
could be made a LITTLE better with a keyboard activated KVM switch.

A co-worker bought himself a foot-switch activated KVM once, but I haven't
seen those ever again on the market.  Another co-worker is happy with those
tiny Logitech trackballs, but leaves a USB mouse simultaneously plugged in
for whenever one of us has to get on his PC to see a particular customer's
system, etc... thank goodness for USB pointing devices!  I like big
trackballs, but use a mouse most of the time.  But I can never get the hang
of his little "thumb-ball".  I'm also a fan of the pointing "sticks" on the
IBM laptops, but I know that many people hate them.  I disable my touchpad
altogether on the T43 and use the stick...

Nate

-----Original Message-----
From: spam_OUTpiclist-bouncesTakeThisOuTspammit.edu [.....piclist-bouncesKILLspamspam@spam@mit.edu] On Behalf Of
Vitaliy
Sent: Friday, January 30, 2009 8:11 AM
To: Microcontroller discussion list - Public.
Subject: Re: [TECH] Agile programming

I find that I'm most productive alone, at night. It doesn't matter whether
I'm home or at work, except for the fact that at work I have access to all
necessary equipment, and a much better computer. :)


2009\01\30@183850 by Nate Duehr

face
flavicon
face
I agree.  Unfortunately we do have hard, fast rules... all the way down to
cubicle sizes.  Strangely, managers are required NOT to have outside
windows.  The put all our managers in a row with floor to ceiling windows in
their little offices that have no blinds (they have to go to conference
rooms for visual privacy), and they're all on an interior wall.  

The "bullpen" is in the center of the space, with a few "large cubicles"
against outside windows.  The "rules" say those are for "leads" and other
technical gurus.  

Most of the technical gurus either use them and hate them (glare on their
monitors from the windows), keep the blinds closed all day, or just elect to
sit in the bullpen area instead for as long as they can get away with, until
Facilities notices their title doesn't match their desk size.

It looks just like a car dealership showroom that had a bunch of cubicles
plopped down in the middle of it, and my boss laughs when we go into his
office and I ask him, "Is it time to sign the loan paperwork for the car,
now?"

Generally he just walks out into the bullpen if we tell him something's up.
We do that via IM or just walking over and someone saying, "You'd better
come see this..."

The other jokes include, "Managers aren't allowed near the windows to keep
them out of the blast radius of the rental truck bomb in the parking lot."
And, lots of good natured ribbing of the "leads" who've ended up in the
outside cubicals about "Hey, I can't read your monitor.  Can you?"

The only good thing about all the cubes... we ALL have our own small
whiteboards.  My favorite feature.  So much so that I hung a small
whiteboard at home not too far from my desk there too...

Nate

{Original Message removed}


'[TECH] Agile programming'
2009\02\05@080817 by olin piclist
face picon face
Vitaliy wrote:
> What I'm hearing from you guys (you, Gerhard, Olin)
> is, "Every project is different. What works for one project may not
> work for another project. What doesn't work for one project may work
> for another project. There are no rules, you must adapt."

Pretty close.  There are of course some general guidlines and methodologies,
but they are just that: general.

> This makes me very uncomfortable, because the implication is that
> experience is irrelevant.

Exactly the opposite, unfortunately.  If experience weren't important, this
could be taught in school and out would pop managers ready to go.  Managing
is a skill that also requires significant knowledge.  You can teach some of
this in school, but like any other skill or discipline, there is much to be
gained from experience.  Experience is required exactly because things need
to be flexible and tailored to the situation, people, customer, physical
contraints, budget, etc.  You can't teach the right choice for all possible
combinations of constraints because there are too many.

The problem is you seem to be looking for a magic formula.  There are at
best broad guidlines.

> In addition, the statements you guys made reveal that you don't really
> know what Agile is. If you don't know what it is, how can you make
> judgements about its effectiveness?

I don't know what Agile is, although from context I suspect I've been seeing
some of its principles applied routinely before someone tried to put a name
on them.  But it doesn't matter what Agile or any other strategy is.  The
point is that no one strategy works universally.  Unless of course that
strategy is so vague and flexible as to be no strategy at all.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\05@085840 by olin piclist

face picon face
Vitaliy wrote:
> Good question. I don't know why, I think they were practiced by a small
> minority, and the majority was educated and encouraged to follow the
> waterfall approach,

You keep saying this, but I don't think the waterfall method is taught like
that.  It's usually mentioned as the "traditional" method, but if you look
under the hood of real projects you won't see one actually adhering to it.

> That's what I figured. I think of Agile as a set of practices that "make
> sense". It's only fault as far as I can tell, is the fact that it has a
> name. :)

Seriously, that is a real problem.  Giving it a name immediately attaches
suspicion.  It sounds too much like a cult.  Part of the problem is that a
named set of rules sounds more rigid.  The named set of ruled may even
largely be a good idea, but any rigid set of rules is going to cause
trouble.  Common sense should always be the first rule.

> In fact, I think deciding it upfront is impossible --
> because too many assumptions would have to be made.

Of course you can't decide everything up front.  But its very useful to know
where you're going even if you set out to implement a small subset then pop
up and look around again.  There are many ways the small subset of features
could be implemented, most of them making it difficult to cleanly add the
remaining features.

Sometimes I get customers that think they know exactly what they want.  I
always make them step back and explain the bigger picture.  Most of the time
what they really want ends up different after some discussion.  I don't want
to start implementing anything until I know the bigger picture it will fit
into.  Only then can I architect the system properly so as to minimize
painting myself into a corner.

> Definitely. Agile development does not preclude requirements gathering.
> Have you ever heard of "Iteration Zero"? The big difference is that
> Agile gathers *just enough* requirements to get started, without trying
> to capture every single detail upfront.

If the "just enough" doesn't include the bigger picture and a good idea of
all the features required, then you'll likely end up painting yourself into
a corner with the early iterations.  It's hard enough to avoid this even
when you do have the bigger picture, looking at the project with tunnel
vision pretty much guarantees it.

>> In fact, while I've heard a lot about the waterfall model, I've never
>> seen it implemented (maybe because the pure model is too far away from
>> reality).

I totally agree with Gerhard here.

> I am of the opinion that there don't exist any projects where 100% of
> the requirements must be gathered before the implementation work can
> begin. You can always start with a small piece, and build the software
> gradually.

Not if you want to be able to use the early work without architectural
changes or scrapping it completely.  Also nobody said you need 100% of the
requirements up front.  You do however need a good idea of the big picture
and all of what the system has to do at a high level, else you're going to
write a lot of throw-away code.

> - We tried to document every detail upfront, literally spending several
> man-months producing nothing but paper.

I'm sure some of that was good.  It's a question of degree.  That's a
judgement call you can't formulate a right answer to.  Some projects do
require high detail up front.  Often I see something the customer considered
a small detail dictating a large change in architecture.  Part of the
problem is something that is a detail functionally may not be a detail to
implementation at all.  Only the implementer or system architect can
distinguish these.

> - We left the contractor out of the requirements gathering process. We
> basically handled him the specs, and said "implement it exactly as we
> tell you to"

If you had come to me with that I would have read the spec, made notes, then
insisted on sitting down with you and made you explain why you wanted each
of the details.  Quite likely there would have been changes to the spec once
I understood what was really important to you and what was merely picked
that way to put something on the spec, and trading those off against
implementation constraints.  If you refused to have this conversation I
probably would have walked away from the job.

> What's probably worse, we asked him to document everything
> he was going to implement, before he implemented it.

A competent consultant would have pushed back hard here and probably walked
away from the job if you persisted.  This kind of micro-managing customer is
way more trouble than they're worth.  It sounds like you got someone that
didn't know what he was doing or was desperate for work.

> The way I would do it now, is:
>
> - I would put together high-level requirements, spending not more than a
> couple of days.
> - Have a meeting with the developer, explain and prioritize the
> requirements

So far so good.

> Have the developer pick a number of features "off the top" that he can
> implement in two weeks

Bad idea, at least in general.  I've had many projects where the nature of
the architecture and the foundations that had to be built precluded
meaningful features within two weeks.  Insisting on instant gratification
runs the serious risk of forcing a bad architecture and either living with
the resulting mess later or having to throw out the early work.

> - Get regular (daily) software updates, and provide feedback to the
> developer

Seeya.  So long.  Get someone else to do this job.

You are micro-managing again.  There needs to be a ballance between your
need to have visibility into the project and the developer's need to have
you off his back and let him get some work done.  Daily updates is going to
be way far off one end for the vast majority of projects.  You are not doing
yourself any favors by insisting on this.

> We could have launched this project when only about 60% of the
> functionality was completed.

Then that should have been a milestone.

> In Agile, the rule is simple: you gather enough requirements to do one
> iteration.

Then what happens when the requirements for the next iteration come along
and you find you did the previous iteration the wrong way to fit on the new
features?  You'll probably hear developers saying things like "I wish we'd
known ...", "If you'd only told us...".

> It sounds like you and Oline have been spared the "scientific
> development" approaches, then. Consider yourself lucky. :)

I'm not up on the latest buzzwords for sets of management rules all bundled
up neatly for easy consumption, so I don't know what you think "scientific
development" means.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\05@165659 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> - Get regular (daily) software updates, and provide feedback to the
>> developer
>
> Seeya.  So long.  Get someone else to do this job.
>
> You are micro-managing again.  There needs to be a ballance between
> your need to have visibility into the project and the developer's
> need to have you off his back and let him get some work done.  Daily
> updates is going to be way far off one end for the vast majority of
> projects.  You are not doing yourself any favors by insisting on
> this.

A useful means can be to have the contractor work with your repository.
IMO this is a reasonable request, and it provides both visibility and no
reporting overhead. Of course if you call after the first couple days
why there isn't any code yet... that's bad then, and an abuse of this
visibility :)

Gerhard

2009\02\06@065607 by Vitaliy

flavicon
face
"Gerhard Fiedler" wrote:
>>> - Get regular (daily) software updates, and provide feedback to the
>>> developer
>>
>> Seeya.  So long.  Get someone else to do this job.
>>
>> You are micro-managing again.  There needs to be a ballance between
>> your need to have visibility into the project and the developer's
>> need to have you off his back and let him get some work done.  Daily
>> updates is going to be way far off one end for the vast majority of
>> projects.  You are not doing yourself any favors by insisting on
>> this.
>
> A useful means can be to have the contractor work with your repository.
> IMO this is a reasonable request, and it provides both visibility and no
> reporting overhead. Of course if you call after the first couple days
> why there isn't any code yet... that's bad then, and an abuse of this
> visibility :)

Gerhard correctly guessed the method for getting the daily updates, without
putting a burden on the developer. :)

I should have clarified, however. We wanted to be a part of the development
process, basically the consultant would be a part of our team. I realize
this would put a lot of people off, maybe it is a bad idea -- I'm not sure
at this point.

If we were simply handing off the project to the consultant, then weekly or
even bi-weekly iteration meetings would have been sufficient.

Vitaliy

2009\02\06@092802 by olin piclist

face picon face
Vitaliy wrote:
> Working code does not lie.

It sure can!

If you're showing the first 20% of the features and giving the impression
that you can just add the remaining features but the architecture is such a
mess that it procludes that, that would be a lie.

I bet everyone that's been in this industry for 20 years has seen a few
cooked or rigged demos where the intent was to give the impression of more
capability than actually existed.  Usually the demo code isn't outright
fradulent (I've seen that too though), but a certain set of inputs were
carefully chosen where everything was known to work, deliberately giving the
impression that the system worked for other cases just as well when it
actually didn't.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\06@093835 by olin piclist

face picon face
Vitaliy wrote:
> I'm not advocating against planning per se, only excessive, overly
> detailed planning that looks too far into the future, and is
> therefore largely based on assumptions.

Ah, see, in the end it all comes down to judgement calls you make based on
things you've learned and you're experience.  I'm sure everyone that is
running a project thinks they are trading off too much planning with too
little about right.  The problem is you can't quantitatively measure this
and decide where the right level is.  Telling someone to plan, but not
excessively or overly detailed is meaningless.  You might as well walk in,
tell them all to do a good job, then leave.  Do you really expect them to
say "Good idea, we didn't think of that"?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\06@095803 by Steve Willoughby

flavicon
face
Olin Lathrop wrote:
> Vitaliy wrote:
>> Working code does not lie.
>
> It sure can!
>
> If you're showing the first 20% of the features and giving the impression
> that you can just add the remaining features but the architecture is such a
> mess that it procludes that, that would be a lie.

I've seen some real horror shows of teams claiming to have done "Agile"
projects, and like any other technique, Agile isn't the panacea for
everything, but I would also point out that what you've described is in
violation of the Agile values and would be seen as poor and
unprofessional (if not outright dishonest) in the Agile camp as well as
anywhere else.

The biggest proponents for Agile methodologies I've spoken with all say
you do as much architectural planning and careful work to make sure you
don't end up with a bandaid-smattered mess when you're done with Agile
as with other methods, but the difference is that you do it in a
different order and in a different way, so you're better able to respond
to changes in the work conditions (who hasn't taken on a large project
only to find after 12-18 months of development that business has changed
in that time, or that the customer *now* realizes that, once they see
the product, they misunderstood or misstated what they were asking for?)

The successful teams I've seen have taken more of a pragmatic approach
to the whole thing instead of a philosophical or religious one, though,
it's not about "doing Agile" or "doing whatever" as much as it is "doing
software development" and if Agile has some things to offer, so much the
better, whether you do them strictly by the book or adapt some things
into your work model to suit your needs.

2009\02\06@100118 by Steve Willoughby

flavicon
face
Steve Willoughby wrote:
> Olin Lathrop wrote:
>> Vitaliy wrote:
>>> Working code does not lie.
>> It sure can!
>>
>> If you're showing the first 20% of the features and giving the impression
>> that you can just add the remaining features but the architecture is such a
>> mess that it procludes that, that would be a lie.
>
> I've seen some real horror shows of teams claiming to have done "Agile"
> projects,

sorry, I left that thought incomplete.  I meant, "claiming to have done
'Agile' projects, but their idea of 'Agile' was either 'slap together
haphazard code' or 'be facists who mistreat and undervalue their
programmers'.  Neither is what I think Agile's meant to be about.

2009\02\06@101340 by olin piclist

face picon face
Steve Willoughby wrote:
>>> Working code does not lie.
>>
>> It sure can!
>>
>> If you're showing the first 20% of the features and giving the
>> impression that you can just add the remaining features but the
>> architecture is such a mess that it procludes that, that would be a
>> lie.
>
> but I would also point out that what you've
> described is in violation of the Agile values and would be seen as
> poor and
> unprofessional (if not outright dishonest) in the Agile camp as well
> as anywhere else.

Absolutely, that was in fact the point.  I was responding to the incorrect
blanket statement that working code doesn't lie.  Making it lie isn't
professional and I'm quite willing to believe against Agile values and most
other values, but it still happens.

> The successful teams I've seen have taken more of a pragmatic approach
> to the whole thing instead of a philosophical or religious one,
> though,
> it's not about "doing Agile" or "doing whatever" as much as it is
> "doing software development" and if Agile has some things to offer,
> so much the better, whether you do them strictly by the book or adapt
> some things
> into your work model to suit your needs.

I agree.  Some managers will have tendencies more towards one model or the
other, but in real life you do what makes sense regardless of what model
might be for or against it.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\06@123315 by olin piclist

face picon face
Rolf wrote:
> 2. Architecture Envisioning - they admit that this is really what I
> would call 'good progect design'... choose the right
> environments/people/teams up front because you really don;t want to
> re-write everything later when your client uses UNIX instead of
> Windows, or some other problem. This is where my 'Wise/Experienced'
> Manager comes in - they instinctively know how a project will have to
> unfold in order to be successful. This setup phase is critical for
> the success of the project...

I'd say this is where the wise/experienced chief engineer/architect comes
in.  The manager has to be smart enough to know to let this guy take the
time to do some good architectural planning up front else there'll be a mess
later.

> "The Agility .. you must embrace ... or a Jedi you are not!" "A
> disturbance in Agility, your document is too early".

ROFL!


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\16@055739 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> I'm not advocating against planning per se, only excessive, overly
>> detailed planning that looks too far into the future, and is
>> therefore largely based on assumptions.
>
> Ah, see, in the end it all comes down to judgement calls you make based on
> things you've learned and you're experience.  I'm sure everyone that is
> running a project thinks they are trading off too much planning with too
> little about right.  The problem is you can't quantitatively measure this
> and decide where the right level is.  Telling someone to plan, but not
> excessively or overly detailed is meaningless.  You might as well walk in,
> tell them all to do a good job, then leave.  Do you really expect them to
> say "Good idea, we didn't think of that"?

Olin, I don't know how you do your planning, but there is a big difference
between upfront planning, and "just enough" planning.

We do just enough planning for one iteration. There's nothing ambiguous
about it. We don't write specifications for features that will not be
implemented in this iteration.

Does this make sense?

This is similar to the YAGNI (You Ain't Gonna Need It) principle: you don't
program features that you think you may use, you only code the ones that you
know you're going to use.

Vitaliy

2009\02\16@060040 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> Working code does not lie.
>
> It sure can!
>
> If you're showing the first 20% of the features and giving the impression
> that you can just add the remaining features but the architecture is such
> a
> mess that it procludes that, that would be a lie.

Notice I said "code". If I (the customer) have a choice between a pile of
documentation, and working code, I will always choose the latter.

I can see what it does, I can see how it's laid out, I can make changes to
it to see if I can break it.

However, even if I don't have access to the code, working software is way
better than documentation.

Vitaliy

2009\02\16@083530 by olin piclist

face picon face
Vitaliy wrote:
> Olin, I don't know how you do your planning, but there is a big
> difference between upfront planning, and "just enough" planning.
>
> We do just enough planning for one iteration. There's nothing
> ambiguous about it.

"Just enough" sounds suspiciously like a judgement call to me.  I think it's
impossible to discuss what just enough is in the general case since every
case is so different.  Without a specific project, we're all just making hot
air.

> We don't write specifications for features that
> will not be implemented in this iteration.
>
> Does this make sense?

No.  I keep saying this and you keep not addressing it, so I'll try one last
time.

In system design you need a good idea what the whole system needs to do
before you can start designing the first piece.  This is because there are
many ways the first piece could be designed, but some ways allow that piece
to fit into the larger system nicely while others proclude it.  Without the
larger context you run the risk of painting yourself into a corner during
early development.

For example, suppose I told you that I needed a PIC system to be a accurate
clock based on WWVB.  You build the receiver, do the WWVB synching.  Now I
tell you I want to see the time displayed.  You go back and lay out the
board again, this time with a bigger PIC and add 7 segment multiplexing.
They I tell you I want the date and 24 hour format.  You have to go back and
redesign the first digit because you simplified it thinking it only ever
needed to be "1" or blank since that's all 12 hour format requires.  That
means you have to juggle pins, change the multiplexing scheme, or possibly
use a bigger PIC.  Geesh, if I'd only told you that at first!  Then I tell
you I really want this clock for network synchronization and it has to be a
NTP server.  Now you have to chuck out the PIC 16 that so nicely did just
the necessary job for the lowest cost...   etc.

> This is similar to the YAGNI (You Ain't Gonna Need It) principle: you
> don't program features that you think you may use, you only code the
> ones that you know you're going to use.

Code yes, but you do have to architect the system for the full feature set.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\17@005253 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> We do just enough planning for one iteration. There's nothing
>> ambiguous about it.
>
> "Just enough" sounds suspiciously like a judgement call to me.  I think
> it's
> impossible to discuss what just enough is in the general case since every
> case is so different.  Without a specific project, we're all just making
> hot
> air.

Do you understand that there is a huge difference between "just enough
planning for the project", and "just enough planning for one iteration"?
This is a serious question, I'm trying to figure out what I need to explain
better.

In the first case, you're making planning decisions months, and maybe years,
in advance. In the second case, you're only doing enough planning to carry
you until the next iteration meeting (one or two weeks away).


>> We don't write specifications for features that
>> will not be implemented in this iteration.
>>
>> Does this make sense?
>
> No.  I keep saying this and you keep not addressing it, so I'll try one
> last
> time.

I'm doing my best, but of course if you feel like I'm not addressing it,
then I'm not doing a good job. You can help me by making an honest effort to
understand, and telling me exactly what does not make sense to you.


> In system design you need a good idea what the whole system needs to do
> before you can start designing the first piece.  This is because there are
> many ways the first piece could be designed, but some ways allow that
> piece
> to fit into the larger system nicely while others proclude it.  Without
> the
> larger context you run the risk of painting yourself into a corner during
> early development.

Brooks says "build the first [system] to throw away; you will, anyway". His
point is that you build the first one to learn from, and then you build the
second one based on that experience.

I don't subscribe to that point of view, but I agree that in general you
can't design a perfect system on the first try.

So what we do, is accept that change is inevitable, and make an effort to
isolate and contain it by employing appropriate design practices. We don't
build one system, throw it away, and write a second one from scratch. What
we do is learn throughout the project, with every iteration building on top
of the ones preceding it. Refactoring is key, it's the one technique that
allows the project to gradually be chiseled into its final form.


{Quote hidden}

Your example is understandably contrived, but here is how I would approach
this project:

First, I would create a quick sketch on a napkin or better yet, a
whiteboard. I would draw a quick block diagram, and a simple drawing of the
product's appearance. "Is this what you want? Do you want 12 hr or 24 hr?
How many users would this NTP server serve? Etc."

Once I think I understand what you need (after 30 minutes of sketching and
asking questions), maybe I could even construct a simple cardboard model.
Does it look like you imagined it?

We could breadboard a part of the circuit, let's see if the 7-segment LED is
big enough/bright enough. "You want a different color? No problem, let's try
this one. Looks OK? Great!"

I would get your feedback as I sit down to do the schematic, and later the
layout. In parallel, I could put together bits of working code, and
demonstrate them to you (sync code, UI, NTP server).

With every new draft, I would get closer and closer to the final product,
without wasting a lot of effort implementing something that I *think* you
want.

------

What I would *not* do, is try to commit every single detail down to paper,
before doing any actual work.

By the way, this is really how we approach things at work. Initial planning
meeting, even for projects that take many months to complete, takes no more
than three hours. We gather only enough requirements and do just enough
planning, for one week (our engineering team is small, and our iterations
are shorter than the "normal" agile ones).


>> This is similar to the YAGNI (You Ain't Gonna Need It) principle: you
>> don't program features that you think you may use, you only code the
>> ones that you know you're going to use.
>
> Code yes, but you do have to architect the system for the full feature
> set.

Not in my experience. It is possible to start with a simple system with only
a subset of the final feature set, and build/refactor it into the final
system. Along the way, you may find that many of the features you considered
important at the outset, are not. Certain features you may have left out
initially because they seemed too difficult to implement, in reality turn
out to be trivial to implement.

We've done it, and I've seen other companies go through the same process.

Vitaliy

2009\02\17@024931 by Vitaliy

flavicon
face
Steve Willoughby wrote:
{Quote hidden}

Well put.


2009\02\17@032617 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> Good question. I don't know why, I think they were practiced by a small
>> minority, and the majority was educated and encouraged to follow the
>> waterfall approach,
>
> You keep saying this, but I don't think the waterfall method is taught
> like
> that.  It's usually mentioned as the "traditional" method, but if you look
> under the hood of real projects you won't see one actually adhering to it.

I know real projects don't work this way. But I know they still teach it in
technical colleges. Just like they still teach Keynesian economics in public
schools.


{Quote hidden}

I like it.


>> I am of the opinion that there don't exist any projects where 100% of
>> the requirements must be gathered before the implementation work can
>> begin. You can always start with a small piece, and build the software
>> gradually.
>
> Not if you want to be able to use the early work without architectural
> changes or scrapping it completely.

Nothing wrong with architectural changes. :) This is software we're talking
about, right?


> Also nobody said you need 100% of the
> requirements up front.

I'm sure Gerhard said something along the lines that on some projects you
need to do most of the design work upfront.


>  You do however need a good idea of the big picture
> and all of what the system has to do at a high level, else you're going to
> write a lot of throw-away code.

I agree with this.


>> In Agile, the rule is simple: you gather enough requirements to do one
>> iteration.
>
> Then what happens when the requirements for the next iteration come along
> and you find you did the previous iteration the wrong way to fit on the
> new
> features?  You'll probably hear developers saying things like "I wish we'd
> known ...", "If you'd only told us...".

I meant "requirements" in the sense of "detailed specifications" (bad choice
of words on my part).  I touched more on this in my other reply.


>> It sounds like you and Oline have been spared the "scientific
>> development" approaches, then. Consider yourself lucky. :)
>
> I'm not up on the latest buzzwords for sets of management rules all
> bundled
> up neatly for easy consumption, so I don't know what you think "scientific
> development" means.

I meant the waterfall approach and CMM, to name two examples.

Vitaliy

2009\02\17@051713 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Olin Lathrop wrote:
>>> Working code does not lie.
>>
>> It sure can!
>>
>> If you're showing the first 20% of the features and giving the
>> impression that you can just add the remaining features but the
>> architecture is such a mess that it procludes that, that would be a
>> lie.
>
> Notice I said "code". If I (the customer) have a choice between a
> pile of documentation, and working code, I will always choose the
> latter.

It seems you've never seen good documentation nor bad code. I'd say in
many "normal" situations I'd go with your choice (for whatever "normal"
is supposed to mean), but I've seen enough good documentation and bad
code that I'd definitely not say "always" here.

For example (the afore-mentioned insurance billing system), you could
have to choose between a good, well-structured documentation of all the
(quite complex) billing procedures of your company, or "working code"
that is not much more than a quick hack-together of some common-place
billing GUI that doesn't address any of the complex intricacies of your
company's billing procedures. What would you choose?

Having the former allows any run-of-the-mill programmer team to put your
billing procedures into program form. Having the latter (without the
former) isn't worth more than a copy of QuickBooks.

Gerhard

2009\02\17@055445 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Olin Lathrop wrote:
>> "Just enough" sounds suspiciously like a judgement call to me.  
>
> Do you understand that there is a huge difference between "just
> enough planning for the project", and "just enough planning for one
> iteration"? This is a serious question, I'm trying to figure out what
> I need to explain better.

I think he does, and so do I. Two issues here...

One is that whatever is "just enough" (no matter for a project or an
iteration) /is/ a judgment call. This comes back to the earlier
conversation about experience: what is "just enough" /is/ experience;
there is no "scientific" rule about how much is enough.

The other is that there are many projects where a single iteration
doesn't produce any business value; business value is only generated
after reaching a certain threshold of functionality, which is so high
that there are a number of iterations necessary to get there. So you
know up front (or could know, if you planned that far) where you need to
go, and you're not as efficient as you could be if you don't plan that
far.


> Brooks says "build the first [system] to throw away; you will,
> anyway". His point is that you build the first one to learn from, and
> then you build the second one based on that experience.
>
> I don't subscribe to that point of view, but I agree that in general
> you can't design a perfect system on the first try.

Reality is that even though the second attempt usually would work out
better, often enough there are only enough funds for one shot. After
selling it for a while, there may then be a second chance for a shot
(but again only for a single shot).

But again (like with the testing before), Brooks's argument is circular.
If I build the first to throw away and the second is then "right", by
the time I build the second, requirements have changed, and the second
will be the new first... and so on. This is true, in that most of the
times I design a system, I learn something that I'd do differently in a
next design. But this is also irrelevant in that most of the time I
design a system, it's the only shot I've got -- because of budget
constraints.



{Quote hidden}

So you would start out by planning for all the required features,
several iterations ahead, "making planning decisions months ... in
advance"?


> Not in my experience. It is possible to start with a simple system
> with only a subset of the final feature set, and build/refactor it
> into the final system. Along the way, you may find that many of the
> features you considered important at the outset, are not. Certain
> features you may have left out initially because they seemed too
> difficult to implement, in reality turn out to be trivial to
> implement.

This doesn't seem to be what you suggested above... You suggested
planning ahead, many iterations, even planning for the NTP server and
Ethernet interface /before/ the initial iteration.

Gerhard

2009\02\17@055915 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Olin Lathrop wrote:
>> You keep saying this, but I don't think the waterfall method is
>> taught like that.  
>
> I know real projects don't work this way. But I know they still teach
> it in technical colleges.

That's a problem with those colleges that has little to do with what
we're discussing here. Apparently most of the students forget about this
-- just as they forget most of the other stuff -- the moment the
semester is over :)


>> Not if you want to be able to use the early work without
>> architectural changes or scrapping it completely.
>
> Nothing wrong with architectural changes. :) This is software we're
> talking about, right?

Now come on... this is software we're talking about, and changing the
architecture in mid-course could easily cost you half a million extra.
If that change was avoidable and it was my money, I probably would be
pissed. The impact depends on the size of the project and other factors,
and can be a real disaster -- and can mean the death of the project (and
possibly the company, if it's a startup, the project is its only one,
and investor funding is running out).

It's not that because it's software, architectural changes are always
easy. You don't need to re-layout a board, but you may have to do a few
things that are just as much work.


>> Also nobody said you need 100% of the requirements up front.
>
> I'm sure Gerhard said something along the lines that on some projects
> you need to do most of the design work upfront.

I don't remember, but it sounds as if I could have said this. What's
your point though? "Most of the design work" is not the same as "100% of
the requirements". There are two important differences: one is "most" vs
"100%" (which means "all"); I hope this is obvious enough. The other is
"requirements" vs "design work". You don't need /all/ requirements up
front, but you need the /important/ requirements up front if you don't
want to waste time. I suggest you better make a reasonable effort to get
the important requirements as early as possible, best before starting
with the first iteration, even if they are not what you plan on working
on during your first iterations. This allows you to do "most of the
(architecture) design" up front, and makes sure that you have a useful
direction for your iterations.

IIRC, one of the Agile mantras is that the best code is the one that you
don't have to write (or along these lines). This is an important one,
and it can also be extended onto refactoring: the best refactoring is
the one you don't have to do. While I'm all for seriously considering
refactoring when it's warranted (instead of kludging stuff on top), I'm
even more for avoiding later refactoring (and coding) where possible by
thinking ahead. Even if this means thinking a few iterations ahead.

Gerhard

2009\02\17@074625 by olin piclist

face picon face
> Brooks says "build the first [system] to throw away; you will, anyway".
> His
> point is that you build the first one to learn from, and then you build
> the
> second one based on that experience.
>
> I don't subscribe to that point of view, but I agree that in general you
> can't design a perfect system on the first try.
>
> So what we do, is accept that change is inevitable, and make an effort to
> isolate and contain it by employing appropriate design practices. We don't
> build one system, throw it away, and write a second one from scratch. What
> we do is learn throughout the project, with every iteration building on
> top
> of the ones preceding it. Refactoring is key, it's the one technique that
> allows the project to gradually be chiseled into its final form.

The obvious approach to me is to gather the requirements you can up front,
take a stab at a reasonable architecture based on what you know, then start
implementing.  The requirements will always change at least a little.  With
good architecture and with some experience with what is likely to change,
the little changes don't usually require large structural changes.  If
something does require large structural changes you're no worse off than in
your system.  Often enough though you do get enough right up front for that
to be useful and therefore save effort in the long run.

> Your example is understandably contrived, but here is how I would approach
> this project:
>
> First, I would create a quick sketch on a napkin or better yet, a
> whiteboard. I would draw a quick block diagram, and a simple drawing of
> the
> product's appearance. "Is this what you want? Do you want 12 hr or 24 hr?
> How many users would this NTP server serve? Etc."

But you're not allowed to do that as it's not required for the first
iteration.  You seem to understand intuitively that this up front planning
is required, but note how this is a lot more than planning for just the next
iteration.  You have to have some idea where you're ultimately going before
you put your head down and dig in to get that first chunk done.

{Quote hidden}

I mostly agree with this, but this is not the process as you have previously
described it.  This is looking ahead a lot more than a single iteration.

> What I would *not* do, is try to commit every single detail down to paper,
> before doing any actual work.

If this were a fixed price project, then lots of details had better be
written down, both for your protection and mine.  These details are the
what, not the how.

>> Code yes, but you do have to architect the system for the full feature
>> set.
>
> Not in my experience. It is possible to start with a simple system with
> only
> a subset of the final feature set, and build/refactor it into the final
> system.

I guess this is the fundamental disagreement that will remain a
disagreement.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\17@085342 by Lee Jones

flavicon
face
I may well regret throwing fuel on the fire that is keeping this
thread alive...


{Quote hidden}

I'm uncomfortable that both sides keep arguing about the single word

   documentation

when it covers such a wide range of information from requirements &
specifications to user manuals.  Trying to write all of it, a priori,
and "casting it in stone" _is_ an impossible task.  But writing down
none of it in advance is a practical impossibility too.

But the vast majority of my clients over many years will _NOT_
sign off on a contract proposal until they know what it will cost
and I won't quote a fixed price until I know what I must deliver.
That mandates a requirements & specifications document up front.

Frequently it appears the business people who sign the checks are
more concerned with the final cost than what gets delivered (within
reasonable limits).  I expect I'd be laughed out of the room if I
proposed that they specify "just enough" to work for two weeks of
work -- and they pay my for that work -- with no up-front guarantee
of what the final product would look like.  That's the reality of
the marketplace that I work within.

And it doesn't have to be cast in stone.  In almost every project
that I have ever worked on, the requirements agreement was revised
one or more times during the construction process.  It does not
matter if it's software, cabling, or a building -- the change order
process (with fees for each change) is well know and understood.

I have had a couple clients who could live with the Agile purist
method -- but they are very rare and it took years to build a
relationship first.


>>> { Document the areas where you would have to make them as "TBD"
>>> or whatever, [...]

>> Then the whole document would have to be "TBD". You're saying that
>> once you document something, it is set in stone.

I've frequently had requirements documents where certain sections
are "TBD".  They get filled in during the project.  Sometimes on
an as needed basis; sometimes after certain milestones are met.

Nothing is "set in stone" until the final check is cashed and
the client doesn't sue you. :-)



In reference to Brook's Mythical Man-Month stating that the first
version of software will be thrown away...

>> I don't know, I end up refactoring most of my code at least once. :)

> That's easily possible. It doesn't affect, however, the fact that
> refactoring is expensive -- and an unnecessary cost if it could have
> been avoided by reasonable thinking ahead a few iterations.

It strikes me that an Agile purist's refactoring of code can be
considered to be "throwing away" the first version of software
in a piece-wise fashion.  At the end of the project, an Agile
program team has written the second version -- one bit at a time.

It's very difficult for any programmer to fully understand all the
application space constraints -- particulary the "unwritten rules"
or "corporate memory" that the workers develop over years/decades
through experience -- until the programmer(s) have been immersed in
the project for a while.  That alone makes it almost a given that
the requirements (as implemented in the software) will change even
if the "requirements spec" is never updated.

                                               Lee Jones


2009\02\17@163002 by Alden Hart

flavicon
face
I've been doing "agile" (so called: iterative, milestone based, spiral,
scrum, XP, lean, etc.) development in some form or another since the
late 80's - rapid build, test, acceptance cycles - all important well
before the agile manifesto was drafted. Kelly Johnson's 14 Skunkworks
rules from the early 1950's embody most of the elements of agile
development - Strong architecture ("hardware requirements") going in,
small, flat teams, low decision overhead, flexibility for change, focus
on inspection ("acceptance"), burn reports, trust, tech and business
joined at the hip, no kibitzers ("chickens"), etc. But I digress. See:
http://www.lockheedmartin.com/aeronautics/skunkworks/14rules.html

One point that's often missed is that agile (et al) is as much (more?)
about managing the customer as it is about managing the development
team. Hence the focus on "product owner" and VOTC (voice of the
customer) roles, product backlog, stories, and all that; specifically to
avoid the 18 month "oh no" moment. Deliver early and often. The rest
supports this.

Alden


Vitaliy wrote:
{Quote hidden}

2009\02\17@194556 by Nate Duehr

face
flavicon
face
"Traditional", and "Agile", are both just models to be able to have a
working knowledge of how the other people on the team are acting.  Neither
produces better code than the other, that I've seen.  And I've seen a lot of
products built both ways.

Once either MODEL is turned into POLICY, they're both wrong, from the
standpoint of working code.

>From the standpoint of a life-long tech support guy, I can say that there
are Engineers that build things that WORK, and Engineers who don't.  I know
which are which in my organization, and especially which ones can follow a
scenario where something is doing the "wrong thing" and understand the
description and fix it.  Those that can't, I avoid as much as possible.
They're better off in a back room writing new code, not writing bugfixes.

Who cares which model they use?  It's a never-ending debate, and five years
from now, something "newer and more interesting" than Agile will come along,
but none of them has yet PROVEN to be 100% effective in lowering bugs by a
significant percentage.  The only thing that does that is lengthening
release-times to the point where the product is no longer viable in the open
market by the time it's released.

The end result is either working code the customer is happy with, or
non-working code or code so "brittle" that the only thing it can handle are
default settings and limited-use scenarios.  Olin's "world" seems (from what
little I know) to be consulting, in which case layering on a "Traditional"
model helps protect the BUSINESS interests of the company providing the
product... they write up what it's supposed to be ONCE and produce that
product.  If the customer didn't understand what they wanted (often the
case), they have to renegotiate a price and start the process over.  The
"Agile" religion would say that this is avoided by continually updating the
spec in small digestible pieces, but the PAYMENT for the product doesn't
work that way in most businesses.  If the business model could be tied to
the Agile development where each little piece is a micro-payment over time,
then that would make sense.  But software businesses don't work that way,
unless you're dealing with HUGE customers who'll give a Purchase Order for
six months to a year worth of development and their business is worth taking
that kind of risk on that any individual little stopping point could be the
last payment from them, ever.

Most of the customers I talk to do NOT WANT to talk to the Engineers
(something an "Agile shop" would want) unless there's something they feel
only their Engineers can adequately describe to us.  They just want the
code, APIs and other documented PRODUCTS to work as described in the
documentation delivered with the product, and to have a conduit back to us
(tech support) when something isn't working as expected, and an
almost-immediate answer on a release date for the patch/fix that makes it
behave the way they expected, or a release date for the next version with
new features they want.

Nate

{Original Message removed}

2009\02\17@195247 by Nate Duehr

face
flavicon
face
#14 is often the one missing in today's HR/legal environments.  Try coming
up with real extrinsic ($) motivation for people to develop new things, and
it often happens...

Tell them "no one gets raises this year" in some silly egalitarian
legal-department fashion, even if their work nets the company billions, and
see if they produce anything other than mediocre work.

Proper incentives work wonders.

Nate

-----Original Message-----
From: piclist-bouncesspamKILLspammit.edu [.....piclist-bouncesKILLspamspam.....mit.edu] On Behalf Of
Alden Hart
Sent: Tuesday, February 17, 2009 2:30 PM
To: Microcontroller discussion list - Public.
Subject: Re: [TECH] Agile programming

http://www.lockheedmartin.com/aeronautics/skunkworks/14rules.html

2009\02\17@220800 by Alden Hart

flavicon
face
Interesting. Skunkworks rule 14 states: "Because only a few people will
be used in engineering and most other areas, ways must be provided to
reward good performance by pay not based on the number of personnel
supervised." I've noticed that Silicon Valley companies founded and run
by engineers (or still run by engineers) usually find a way to act on
rule 14.

The agile manifesto only has 12 principles (included below for
reference). Looks like they had to cut 2 rules - so the compensation one
was one of the ones to go.

[Please don't think that I'm disparaging the thinking behind the agile
movement. I'm not. I was quite relieved that someone put down on paper
what I had been (with limited success) trying to communicate for years.
My only complaint is that it is (1) seen as something new, (2)
Capitalized, and (3) sounds a bit like a marxist / leninist screed. I
guess that's a compound complaint.]

Alden

------------------------

Principles behind the Agile Manifesto
http://agilemanifesto.org/principles.html

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

------------------------

Nate Duehr wrote:
{Quote hidden}

2009\02\17@222127 by Nate Duehr

face
flavicon
face

On Feb 17, 2009, at 8:08 PM, Alden Hart wrote:

> Interesting. Skunkworks rule 14 states: "Because only a few people  
> will
> be used in engineering and most other areas, ways must be provided to
> reward good performance by pay not based on the number of personnel
> supervised." I've noticed that Silicon Valley companies founded and  
> run
> by engineers (or still run by engineers) usually find a way to act on
> rule 14.

Hmm, maybe for the first few products.

Ask any HP Engineer what they make if they make the company a few  
million bucks with their work, or any other large "Silicon Valley"  
company that grew OUT of Silicon Valley.

Or better yet, ask the support staff what they get if they SAVE a  
million dollar a year account when an Engineer screws something up and  
they have to placate a ticked off customer.

In both cases, they probably just get to keep their jobs, these days...

Nate

2009\02\18@024729 by Vitaliy

flavicon
face
Alden Hart wrote:
> The agile manifesto only has 12 principles (included below for
> reference). Looks like they had to cut 2 rules - so the compensation one
> was one of the ones to go.

They do say "build projects around motivated individuals". :)


> [Please don't think that I'm disparaging the thinking behind the agile
> movement. I'm not. I was quite relieved that someone put down on paper
> what I had been (with limited success) trying to communicate for years.
> My only complaint is that it is (1) seen as something new, (2)
> Capitalized, and (3) sounds a bit like a marxist / leninist screed. I
> guess that's a compound complaint.]
>
> Alden

Alden, can you explain to me why it seems to you that way? Especially the
first point?

>From what I can tell, agilists readily admit that they did not invent Agile,
that the principles were there all along, and that all they did was committ
it to paper and make it easier for the engineers to make their organizations
accept it. Wikipedia entry on Agile says:

"Gerald M. Weinberg: We were doing incremental development as early as 1957,
in Los Angeles, under the direction of Bernie Dimsdale [at IBM's
ServiceBureau Corporation]. He was a colleague of John von Neumann, so
perhaps he learned it there, or assumed it as totally natural. I do remember
Herb Jacobs (primarily, though we all participated) developing a large
simulation for Motorola, where the technique used was, as far as I can tell,
indistinguishable from XP. [. . .] All of us, as far as I can remember,
thought waterfalling of a huge project was rather stupid, or at least
ignorant of the realities. I think what the waterfall description did for us
was make us realize that we were doing something else, something unnamed
except for "software development. quoted in Larman, Craig; Victor R. Basili
(June 2003)."

I use "Agile" as a generic term, there are other lean methodologies (SCRUM,
XP) that share the essential characteristics. "Deliver early and often" is
one of them.

Vitaliy

2009\02\18@070134 by Alden Hart

flavicon
face
Vitaly,

I guess my objection to "seeing agile as something new" (point 1) is
that this assumption of newness (and by extension inherent correctness)
can lead to bad outcomes if you are not careful. Sort of the
tablets-from-the-mountain effect. I believe the drafters of the agile
manifesto know that this is all old stuff, but many naiive practitioners
do not. This can foster "level 1" behavior, which can be bad. My company
leads agile development for projects with lots of clients and are
constantly bringing people along, so I've seen a lot of new adopters.

In Alistair Cockburn's excellent book, "Agile Software Development: The
Cooperative Game" he describes level 1, 2 and 3 practitioners of an art
(he credits the origin to martial arts). Level 1 practitioners get a
rule book (methodology) and follow the rules religiously (Wax on Wax
off, Paint the fence). Level 2 know multiple rule sets and when to mix
and match, or ignore. Level 3 don't even necessarily know what rules
they are following - they just do the right thing. By this point it's
innate. I believe the manifesto drafters are all L3 types that thought
to distill this wisdom.

I've seen this L1 assumption of newness (and unassailable correctness)
cause projects to run into trouble that could have been avoided if the
client backed down a bit and practiced some more L2 (or L3) behaviors.
For example, the Scrum noisy chickens thing. Sometimes those chickens
know something that will save you a lot of time or mistakes, but they
are not allowed to talk during the standup meeting. Ridiculous. A more
experienced scrum master will let the chicken speak, then shut them up
once they've made their point.

But I guess you have to go through L1 to get to the rest so that's why
they need a guide, which they sometimes ignore because how could the
guide possibly know more than the drafters who wrote the rulebook they
are so assiduously following?

That's a little roundabout, but I hope I conveyed the main point.

Alden


Vitaliy wrote:
{Quote hidden}

2009\02\18@083040 by olin piclist

face picon face
Alden Hart wrote:
> Please don't think that I'm disparaging the thinking behind the agile
> movement. I'm not. I was quite relieved that someone put down on paper
> what I had been (with limited success) trying to communicate for
> years.  My only complaint is that it is (1) seen as something new, (2)
> Capitalized, and (3) sounds a bit like a marxist / leninist screed. I
> guess that's a compound complaint.

Well put.  One more objection that I have is that after capitalizing the
name and writing down the "manifesto" (I think of Ted Kaczynski and Karl
Marx every time I hear that), too many people take it as a new gospel and
forget to apply common sense.  At best, these things are general guidelines
that may have worked well for the originators in their particular
situations.  Unfortunately the manifestos always leave out the limitations
and guidance on when the method is not appropriate.

Vitaliy asked why ignore wisdom from others and used the analogy of a junior
mechanic not following the established proceedure for replacing a
transmission when senior mechanics had done this a bunch of times and found
a good way to do it.  I was getting tired of this thread, so I just let it
pass at the time but I'll answer now.

There are several things wrong with this analogy.  First all 1972 Pintos
with the 1.6L engine and manual transmissions are deliberately as alike as
possible.  It is possible for a few experts to find a good way to perform
the procedure and then just tell others how to do it.  It's basically the
same job every time.  On the other hand, every software project is
different, and the range of differences is vast.  I have no doubt that
Agile-like practises can work well in some situations, but can also see they
would be a disaster in others.

The second point is that while you have master mechanics and junior
mechanics, the distinction isn't so clear with software project managers.
Anyone can write a book.  That doesn't make them a expert and what they say
right.  Conversely, the vast majority of competent managers that know how to
do this right thru experience, some learning, and some innate intuition
don't write books about it and don't teach it to others in a school.  In
fact, it's usually the ones that aren't so good at it that teach it to
others in a school.  There are exeptions of course, but since good managers
make a lot more than good teachers, there is a strong pull on good managers
to manage instead of teach.  Even if the right person writes a book based on
his experience from a lifetime of successes, the world of software
development is so varied that it should not be taken for granted that it
applies outside that person's particular set of conditions.

Put another way, there are so many software projects going on with so many
varied constraints, that just by random chance you're going to find a few
people that adhere to some project management religion or another that have
had nothing but successes.  All one of them has to do is write a book about
it, give it a pretentious marketing name, and poof you've got the latest
Method of the Week.  This week it's Agile, maybe next week it'll be Rigid,
or UpYours, or FreePizza, or whatever.  Some of these may be at least of
passing interest to get some pointers from, but whatever you do, don't ever
ever drink the grape Koolaid.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\02\24@034838 by Vitaliy

flavicon
face
Alden Hart wrote:
> I guess my objection to "seeing agile as something new" (point 1) is
> that this assumption of newness (and by extension inherent correctness)
> can lead to bad outcomes if you are not careful. Sort of the
> tablets-from-the-mountain effect. I believe the drafters of the agile
> manifesto know that this is all old stuff, but many naiive practitioners
> do not. This can foster "level 1" behavior, which can be bad. My company
> leads agile development for projects with lots of clients and are
> constantly bringing people along, so I've seen a lot of new adopters.

I'm relatively new to Agile, but it was clear to me from the beginning that
it isn't new.


> In Alistair Cockburn's excellent book, "Agile Software Development: The
> Cooperative Game" he describes level 1, 2 and 3 practitioners of an art
> (he credits the origin to martial arts). Level 1 practitioners get a
> rule book (methodology) and follow the rules religiously (Wax on Wax
> off, Paint the fence). Level 2 know multiple rule sets and when to mix
> and match, or ignore. Level 3 don't even necessarily know what rules
> they are following - they just do the right thing. By this point it's
> innate. I believe the manifesto drafters are all L3 types that thought
> to distill this wisdom.

I read the first edition of this book.


> I've seen this L1 assumption of newness (and unassailable correctness)
> cause projects to run into trouble that could have been avoided if the
> client backed down a bit and practiced some more L2 (or L3) behaviors.
> For example, the Scrum noisy chickens thing. Sometimes those chickens
> know something that will save you a lot of time or mistakes, but they
> are not allowed to talk during the standup meeting. Ridiculous. A more
> experienced scrum master will let the chicken speak, then shut them up
> once they've made their point.

This is actually how this was explained to me. The chickens can talk, but
they cannot force the pigs to make decisions. Because after all, the
chickens are merely involved, but the pigs are committed. The chickens can
cluck without having to worry about their bacon. :)


> But I guess you have to go through L1 to get to the rest so that's why
> they need a guide, which they sometimes ignore because how could the
> guide possibly know more than the drafters who wrote the rulebook they
> are so assiduously following?
>
> That's a little roundabout, but I hope I conveyed the main point.

So what about you, what do you think about "properly implemented" Agile?

Vitaliy


2009\02\24@114732 by Alden Hart

flavicon
face
Vitaliy,

Getting to your question at the end of your post (So what about you,
what do you think about "properly implemented" Agile?):

"Properly implemented" is the question - isn't it. I always use a
smattering of agile practices because I haven't found a faster or more
efficient way to get to a quality product. First you have to swallow
hard on the need for some amount of rework, and some level of
uncertainty going into a project. Accountants and CFO types hate this,
but it's reality.

What is quality - what is "good enough"? We usually try to define that
up-front in terms of some quantitative and qualitative "quality
criteria". It helps to know when you are done. Some is very easy to
define (e.g. response times <X, round trip latency <Y), some is harder
(e.g. a new user should be able to accomplish the transaction with no
prior training in less than 90 seconds).

I find the hardest part about agile to be properly folding in
longer-term architectural concepts. Too little and you end up with
bandaids or monoliths, too much and you overengineer the thing from the
outset. Agile's professed short-term focus (e.g. on sprints and
iterations) can be a problem if I'm not careful. A team makes the
tradeoffs they are incentivized to make - like get it shipped or get it
"right".

I find that having a high-level architecural vision up front is
essential - such things as the desired characteristics for load
handling, fault tolerance and exception handling, a good understanding
of supported geographic deployment models (the latency question),
MTBF/MTTR targets, as well as some level of data model definition and
extensibility requirements - all help frame the problem and avoid short
terms hacks that can hurt you too much later.

I guess it comes down to trying not to over-analyze things before you
start building, then giving yourself enough iterations to correct the
inevitable mistakes or re-thinks (giving yourself more than one chance
to get it right). In areas where I am reasonably expert (been doing it
for a long time) I can start coding with very little up-front analysis -
trusting to get the details more or less right as I get to them. In
areas where I have less experience there is a lot more analysis up front
and things move slower. And there is inevitably more re-work later -
either in the form of fixing mistakes or finding better solutions to
problems (and some refactoring).

Alden


Vitaliy wrote:
{Quote hidden}

2009\02\25@030134 by Vitaliy

flavicon
face
Alden Hart wrote:
> A team makes the
> tradeoffs they are incentivized to make - like get it shipped or get it
> "right".

I largely agree with everything you said. However, I believe it is possible
to provide incentives to get both. The reason any project is late, is
because the teams tries to do too much. It is better to get fewer features
done, but get them done right -- which I think Agile with its emphasis on
customer value and interations, is very good at.

{Quote hidden}

I think I mentioned before that I follow the student projects at a local
university. In the vast majority of cases, the project does not work on the
Judgement Day. I think it has a lot to do with how the students are taught
to approach the projects: in a pure waterfall fashion.

Even the bright ones fall into this trap. We hire them anyway, and gently
reindoctrinate them, :) but it would save them much grief if only they put
all the pieces together once every couple of weeks, instead of during the
final week of the project.

Vitaliy

2009\02\25@140730 by Alden Hart

flavicon
face
As far as your "last week of a student project" trap goes: I saw the
same behavior and failure on many many projects in college. Except the
egg drop contest (egg must survive 4 story drop with minimal
protection). Then people were trialing their solutions weeks in advance.
Go figure.

Alden


Vitaliy wrote:
{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...