Searching \ for '[TECH] Upfront requirements and lean development' 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/index.htm?key=upfront+requirements
Search entire site for: 'Upfront requirements and lean development'.

Exact match. Not showing close matches.
PICList Thread
'[TECH] Upfront requirements and lean development'
2009\02\18@023837 by Vitaliy

flavicon
face
Olin Lathrop wrote in [TECH] Agile programming:
> 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.

I have absolutely no problem with what you've said above, as long as the
scope of "gather the requirements up front" is limited to what you need for
the first iteration (I know I've said it before, I'll address it in more
detail below).


{Quote hidden}

Aha! So this is what's creating the confusion. :)

The difference between planning for the first iteration and for the entire
project is subtle, but very profound.

When you're planning for the first iteration, you look at the big picture
first. What are the high-level requirements? Ok, so this gadget must have an
LCD, four buttons, a USB port, five A/D channels, and the firmware must be
upgradeable.

Now let's decide which features will be implemented in the first
iteration -- let's say, reading the A/D channels and displaying the output
on the LCD. These are the only things that need to be spec'd out in detail.
On a medium-sized project (say, three months) this means that only..

   (2 weeks/iteration)/12 weeks * 100% = 17%

... of the functionality must be hashed out in detail. It doesn't make sense
to be hashing out the details of the secure bootloader and the kind of
encryption scheme it will be using, until we get to it. High-level
requirements are good enough for the first iteration. The bootloader may not
be implemented at all, so creating the specs for it could end up being a
complete waste of time.

I am contrasting this with doing 100% (or close to it) of the planning and
design work upfront.


{Quote hidden}

No, not really. All of what I described would be done over several
iterations. But I would say that most could be done during the initial
meeting.


>> 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.

I don't do consulting, but I believe you that this is probably how it is
done in the majority of the cases. The problem is that initially, the
customer does not know exactly what he wants. You can try to get him to
think of everything, and commit it to paper. Or you can build a series of
prototypes that gradually approach the final product.

In fact, that is the whole point of agile contracts: they mostly describe
the approach and the expectations, not the end result.


{Quote hidden}

Olin, well don't you ever start with a set of requirements for a product,
and then add more features to this product? Couldn't you then say that the
initial design had only a subset of the functionality? It is done all the
time, you start with a simple design and eventually add more bells and
whistles.


Vitaliy

2009\02\18@091522 by olin piclist

face picon face
Vitaliy wrote:
{Quote hidden}

You are confusing architecture with detailed design.  I never advocated
doing the whole design up front.  You do, however, have to have a good idea
of the architecture before designing individual pieces.

Using your example above, the gadget needs a LCD, four buttons, USB, five
A/D inputs, and a bootloader.  My point is you don't just want to dive in
writing the button code, for example, without having given thought to the
overall architecture.  There are many ways you could check the button state
and debounce it.  It could be done solely in a foreground loop, using
interrupt on change, sampling in a periodic interrupt, external hardware
aggregation, and probably a few more.  None of these are right or wrong by
themselves.  You can only decide the best way after looking at the whole
system.  That's what the architecture is all about.

You need someone experienced with the processor and its available hardware
to do a good job with this.  In this case I would probably run the USB
totally from foreground code and use one periodic interrupt to check and
debounce the buttons and initiate a new A/D reading.  Without a thought-out
architecture, which means knowing all the requirements up front to the
extent that is possible, you could end up with individual subsystems that
work but the whole not working when put together.  You might end up with,
for example, a A/D module and a button debounce module that both used the
same timer in incompatible ways.  It takes a higher level view of the whole
project beyond just the next iteration to prevent problems like this.

> I don't do consulting, but I believe you that this is probably how it
> is done in the majority of the cases. The problem is that initially,
> the customer does not know exactly what he wants. You can try to get
> him to think of everything, and commit it to paper. Or you can build
> a series of prototypes that gradually approach the final product.

You leave out the most common approach, which is you figure out what he
wants by making him pop up a few levels and describe his real problem.  Then
you come back with a proposal that may be totally different than what the
customer originally asked for,  You'd probably be surprised how often this
happens and how often you hear something like "Wow, yes, that's what we
*really* want.  We didn't think of it that way, and nobody else we talked to
mentioned anything like this.".  Frankly, being able and willing to force a
look at the true problem and think out the architecture up front is probably
the most important distinction between a good consultant and a bad one.

Mostly customers don't want implementations, they want solutions.  One of
the more important things a consultant does is to find out what the true
problems are and address those.  Never take the customer's initial word for
what he wants.  Sometimes they do know enough engineering and are familiar
with the range of possible solutions to understand how they want it done,
but this is really quite rare.  Sometimes it's not easy to get the customer
to pop up a few levels and describe the real problem because they often
don't understand it that way themselves.  Sometimes you realize as a result
you're in a no-win situation and you bail.  This is another point where
exprience is important.  Inexperienced consultants don't know when to bail
out and get stuck in bad situations as a result.  (Even experienced ones do
too occasionally, but less often.)

The point is this all takes up front planning to get to the architecture
stage before any implementation is started.

> In fact, that is the whole point of agile contracts: they mostly
> describe the approach and the expectations, not the end result.

That's not a contract at all, or at least not one that most customers would
ever sign, and probably not most competent consultants either.  Customers
need to know what they will get, when, and how much it's going to cost.
Surely you can understand the need for that?  Let's say you asked me to
design the next OBD-II whizbang gizmo for you.  Would you be happy if I said
"Yeah, we can do that.  I'm not sure when it will be done, how much it will
cost, and we haven't agreed on most of the features, but send me $10/month
and I'll try to do something useful."?  Such arrangements do happen, but
they are very rare indeed.


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

2009\02\18@135445 by Alan B. Pearce

face picon face
>You'd probably be surprised how often this happens and how
>often you hear something like "Wow, yes, that's what we
>*really* want.  We didn't think of it that way, and nobody
>else we talked to mentioned anything like this.".

Reminds me of a customer we had at a previous employ. Our company sold
computer hardware, and had several vertical software packages, one being a
package for motor vehicle dealers. A machine was sold to a dealer, but he
insisted on modifications to the package to fit their current way of doing
things in the dealership. Later on apparently he admitted that the 'bog
standard' package is what he should have gone with, and modified his
operation to suit, because the package had been properly thought out as a
way of handling the business, instead of his 'grown like topsy' system.

2009\02\18@152830 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Aha! So this is what's creating the confusion. :)

Not really... see below.

> I am contrasting this with doing 100% (or close to it) of the planning
> and design work upfront.

I'm programming for 25+ years and have participated in several projects
small and big for a number of companies, but I've never seen that 100%
(or close to it) of detailed design was done up front. This may happen
in some government agencies or NASA or whatever, but possibly not even
there.

So... I'm not sure where it is that you disagree with me or Olin or
Rolf. You say that you do, but when talking about examples, it seems you
don't. Your common sense seems to prevail... possibly against your will
:)


> In fact, that is the whole point of agile contracts: they mostly
> describe the approach and the expectations, not the end result.

What's the difference between the expectations and the end result (that
supposedly satisfies those expectations)? If the end result doesn't
satisfy the expectations, there will be some kind of dissatisfaction,
which I'd say is not good. If it does much more than expected, it's
probably more expensive than it would have to be, which also tends to
create dissatisfaction. If it satisfies approximately the expectations,
it kind of used the expectations as specification. So what's the
difference between "specifying the end result" and "describing the
expectations"?


> Olin, well don't you ever start with a set of requirements for a
> product, and then add more features to this product? Couldn't you
> then say that the initial design had only a subset of the
> functionality? It is done all the time, you start with a simple
> design and eventually add more bells and whistles.

You said it: it's being done all the time. And it has been done all the
time. Nothing has changed here with Agile, at least not in my world.

Gerhard

2009\02\23@025223 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
>> I am contrasting this with doing 100% (or close to it) of the planning
>> and design work upfront.
>
> I'm programming for 25+ years and have participated in several projects
> small and big for a number of companies, but I've never seen that 100%
> (or close to it) of detailed design was done up front. This may happen
> in some government agencies or NASA or whatever, but possibly not even
> there.
>
> So... I'm not sure where it is that you disagree with me or Olin or
> Rolf. You say that you do, but when talking about examples, it seems you
> don't. Your common sense seems to prevail... possibly against your will
> :)

Gerhard, for some reason you are trying to make it sound like I'm
contradicting myself. I too feel that what you've said lately, contradicts
your later assertions (including what you said about documentation, and
sharing experience). Have you considered that maybe you don't fully
understand what I'm trying to say, instead of assuming right off the bat,
that I'm confused?

Vitaliy

2009\02\23@040109 by Vitaliy

flavicon
face
Olin Lathrop wrote:
> You are confusing architecture with detailed design.

Olin, with all due respect, I'm not confusing anything. Just because you
didn't understand what I said, or vice versa, doesn't mean we're confused.
Language is not perfect, that's why we have these back-and-forth
conversations. They would not be necessary if we could telepathically
exchange our thoughts. :)


> I never advocated
> doing the whole design up front.

And I never said that you did. I simply tried to clarify the part that was
creating confusion, by contrasting it with 100% planning and design work
upfront. I understand that you don't advocate doing the whole design up
front, Gerhard admitted that he never does either, so I'm glad that at least
we have a consensus on this point.


> You do, however, have to have a good idea
> of the architecture before designing individual pieces.

I agree with the statement, for reasonable values of "good". Just so we're
not dealing with complete abstractions, think about the projects you've
done. What was the maximum amount of time you ever spent on designing the
architecture upfront, expressed as % of the total time spent on the project?

I haven't worked on very large projects, but I have worked on projects that
required several man-months to complete. At the beginning, we would spend
maybe a day (3-5 hours) talking about the architecture, and specifying the
details for the first iteration. This was followed by jumping right into
implementation: putting together the schematic, prototyping the unproven
areas, writing code. New things were learned during that time, so the
following week we would make changes to the original plan, and do some more
development. As the project progressed, certain things sort of just fell
into place ("hey, we have room for the Bluetooth module connector, let's add
it"). Talking about these things at the beginning would have meant making
lots and lots of assumptions, because the necessary information was not
available then.


{Quote hidden}

Taken to the extreme, this can lead to paralysis by analysis. The project is
very simple, and I'm guessing you are thinking of using a low-end processor,
which requires you to think at a lower level (closer to the hardware).

I think more in terms of cohesive, loosely coupled modules. The question
then becomes: "can this feature be implemented?" down the road, not "how
will it be implemented?"

Then again, even if a wrong decision is made because we did not spend the
time to follow every path, and did not consider every single detail, chances
are it's cheaper to back up and make the necessary changes, than to do this
sort of exhaustive planning upfront.

Just so we're clear -- yes, I do consider thinking about how you're going to
implement button debouncing at the beginning of the project, is probably too
much planning. I know that I need buttons, I know I need to allocate enough
inputs, but I don't need to figure out how the function is going to work. I
will deal with this problem, when I get there.


[snip]
> It takes a higher level view of the whole
> project beyond just the next iteration to prevent problems like this.

I tried to explain it last time, and for some reason (based on your
statement above) I'm still not getting through.

Of course you need to plan ahead, beyond the next iteration. But you need to
do only enough planning to do the next iteration. Does it still sound like a
contradiction to you?

You only need to look at things that will affect the next iteration
(including high-level architecture). If the parts are sufficiently
decoupled, you don't need to worry about the design of module B, while you
work on module A.


> The point is this all takes up front planning to get to the architecture
> stage before any implementation is started.

I am not against upfront planning. Neither is Agile or any other lean
methodology I'm aware of.


>> In fact, that is the whole point of agile contracts: they mostly
>> describe the approach and the expectations, not the end result.
>
> That's not a contract at all, or at least not one that most customers
> would
> ever sign, and probably not most competent consultants either.

"Not a contract", and "not ... competent", by your definition. :)


> Customers
> need to know what they will get, when, and how much it's going to cost.
> Surely you can understand the need for that?

I understand the urge to fix the scope (I've been there myself). I also
understand that a customer cannot possibly give you enough information in
order for you to provide an accurate quote. Your estimate would be either
too high, or too low.

I'm not saying you should not provide an estimate. But I think that you
should honestly tell the customer that it is an educated guess based on the
best information available to you at the time, and that most likely it is
wrong.


> Let's say you asked me to
> design the next OBD-II whizbang gizmo for you.  Would you be happy if I
> said
> "Yeah, we can do that.  I'm not sure when it will be done, how much it
> will
> cost, and we haven't agreed on most of the features, but send me $10/month
> and I'll try to do something useful."?  Such arrangements do happen, but
> they are very rare indeed.

Another straw man fallacy. I will not waste my time explaining again, how
agile contracts are done (if you missed it, go back and read my message --  
or use Google).

I will say however, that there are consultants on this list that refuse to
provide a fixed cost estimate (remember, several years ago I actually
submitted an RFQ for an OBD-II gizmo?). They want to bill the customer on a
T&M basis.

Agile contracts are different from both approaches, and IMO a lot more
transparent and fair to both the customer, and the developer.

Vitaliy

2009\02\23@055526 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Gerhard, for some reason you are trying to make it sound like I'm
> contradicting myself. I too feel that what you've said lately,
> contradicts your later assertions (including what you said about
> documentation, and sharing experience). Have you considered that
> maybe you don't fully understand what I'm trying to say, instead of
> assuming right off the bat, that I'm confused?

I'm not saying that you're confused, and I may very well not fully
understand what you're trying to say.

The whole thing started, IIRC, with you saying that some things changed
profoundly in the software development world with the Agile Manifesto,
contrasting it with the waterfall school of project management. One of
my points was that IME in the software development world I've never seen
a place that would use either method in its pure form. All I knew use
some kind of "personalized mix" (that often enough changes with the
project, especially in contract development) -- and while the various
discussions and publications around "lean" methods (starting way before
the Agile Manifesto) did influence these mixes, some more, some less,
the Agile Manifesto itself doesn't seem to have had a profound impact.

And I continue to think that the Manifesto is cute but not profound. All
the statements and sound bites in there have a relation to reality as I
see it, but most if not all need context and have limits -- and
therefore don't apply everywhere, and you have to discover and decide
whether a given one applies to your given situation. I also think that
the Agile world is full of good things to read and consider -- and also
full of crap. Which leads us to another affirmation of mine that was the
basis of this whole collection of threads: it has always been, and
continues to be, an individual judgment call to say when enough of a
good thing is enough -- or what's a good thing to start with :) The
Agile Manifesto didn't change this.

As I said, I participated in projects where they or we spent
considerable time gathering and documenting requirements before writing
a single line of code (over a year, in one case) -- and where this was a
good thing. I've also participated in projects that wasted a lot of time
and money because they tried to shoot too far in a single shot, of
course... But the thing is: both types exist, the Agile Manifesto's
attempt to define away the former notwithstanding.


This is not to say that the Agile Manifesto didn't have a profound
impact on /your/ view of project management -- it may well have had;
only you can tell (and you seem to say it had). But this can't really be
extrapolated to the software development world at large.

Gerhard

2009\02\23@060811 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Of course you need to plan ahead, beyond the next iteration. But you
> need to do only enough planning to do the next iteration. Does it
> still sound like a contradiction to you?
>
> You only need to look at things that will affect the next iteration
> (including high-level architecture). If the parts are sufficiently
> decoupled, you don't need to worry about the design of module B,
> while you work on module A.

IMO this works, but only with certain types of projects and certain
types of relationships between the people involved in the project. There
are projects where this doesn't work well, and examples can be found in
the previous posts on these threads.

This is the whole story, it seems: The methods you are describing are
not bad, but they are not universally good (that is, applicable to every
project in every situation). Or, if you want to see it differently,
"enough planning to do the next iteration" is a judgment call, and may
mean anything from "almost no planning" (if that's enough) to "have the
whole project pretty much laid out" (if that's what is needed).


> I understand the urge to fix the scope (I've been there myself). I
> also understand that a customer cannot possibly give you enough
> information in order for you to provide an accurate quote. Your
> estimate would be either too high, or too low.

Sometimes they can, and of course an estimate is only an estimate. But
some customers prefer to pay more (on average), contracting on a fixed
price basis, but pretty much know (given a responsible and capable sub
contractor) what they have to budget to get what they want.


> I will say however, that there are consultants on this list that
> refuse to provide a fixed cost estimate (remember, several years ago
> I actually submitted an RFQ for an OBD-II gizmo?). They want to bill
> the customer on a T&M basis.

Of course. There are cases where the requirements are not clear enough,
and can't be, at the start of the project. I don't think anybody ever
said that the methods you describe can't work or aren't adequate or even
the best possible choice -- given the right situation. It's mostly your
claim that they are good and adequate for /all/ software development
projects that has people respond that they have participated in projects
where some of this just doesn't work.

Gerhard

2009\02\23@064057 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
> The whole thing started, IIRC, with you saying that some things changed
> profoundly in the software development world with the Agile Manifesto,

Never ever have I said that. And "the whole thing started" when Rolf made
comments about agile that I knew weren't true.


{Quote hidden}

I won't waste my breath trying to convince you that Agile is not full of
crap; you've made up your mind. If someone else wants to find out what Agile
is, the information is out there.


> As I said, I participated in projects where they or we spent
> considerable time gathering and documenting requirements before writing
> a single line of code (over a year, in one case) -- and where this was a
> good thing. I've also participated in projects that wasted a lot of time
> and money because they tried to shoot too far in a single shot, of
> course... But the thing is: both types exist, the Agile Manifesto's
> attempt to define away the former notwithstanding.

It seems impossible to me that you can spend a whole year producing nothing
but paper, and be better off than if a more iterative approach was used. At
least I haven't misunderstood what you were saying. I think this kind of
approach is totally wrong, but of course you're entitled to think "it was a
good thing."  I'd be curious to know who Olin would side with, he recently
said that he never argued for 100% design upfront.

More information about the nature of the project would have been useful.


> This is not to say that the Agile Manifesto didn't have a profound
> impact on /your/ view of project management -- it may well have had;

Yes, this is precisely what I have been saying.


> only you can tell (and you seem to say it had).

Yes, it had.

It's funny when people diss on certain aspects of lean development, and try
to convince me that it cannot work -- when I used it, and it worked, and we
as a company continue to use it with much success. You will have about as
much success convincing me that I don't have a mother. :)


> But this can't really be
> extrapolated to the software development world at large.

I never said that Agile had a profound impact "on the software development
world at large." In fact, I said many times that the knowledge was out there
long before the Agile Manifesto. Which contradicts your (and Olin's) notion
that every project is different, and therefore there can be no rules.

Vitaliy

2009\02\23@072101 by Alan B. Pearce

face picon face
>I'd be curious to know who Olin would side with, he recently
>said that he never argued for 100% design upfront.

However he has consistently argued for architecture design to be well done
right up front.

I take this to mean block diagrams and the like that allow one to make
judgment calls about how various bits are going to be done, so one doesn't
end up in a potential mess like the example he gave early on in this
multithreaded topic.

I do recall being involved in projects where the planning did make
allowances for added features in possible future models, and most of these
models with added features never made it to development stage, but the
architecture allowed for it - and I think this is the point that both Olin
and Gerhard are attempting to make - the planning shouldn't be short cut,
just because something is seen as a minimalist project.

So 'this' project requires 3 switches and 4 LEDs, but why shouldn't the
software interface for the module handling these allow for expansion.

2009\02\23@073942 by Jake Anderson

flavicon
face
Alan B. Pearce wrote:
{Quote hidden}

Because adding the ability to expand it involves more work and bugs that
may never be used in the finished product.

If you want to expand it at a later date, then add the stuff to expand
it then.

2009\02\23@081530 by Rolf

face picon face
Vitaliy wrote:
> Gerhard Fiedler wrote:
>  
>> The whole thing started, IIRC, with you saying that some things changed
>> profoundly in the software development world with the Agile Manifesto,
>>    
>
> Never ever have I said that. And "the whole thing started" when Rolf made
> comments about agile that I knew weren't true.
>
>  


Lets get some things straight.

I guess I 'started' the whole thing when I likened Olin's PIC Dev.
environment to Agile computing. What I said was:

====
The best analogy I can think of is 'Agile Programming'... sure, it
works, and it works well for some people, but it is not for everyone,
and you can get programs that work just as well using other more
traditional ways. Still, it has advantages and disadvantages.
====

What was not true about that?


What happened then was that you queried me on my experience with
Agile.... you asked:

====
I'm curious -- what is your experience with Agile? Can you address the
points you made, in more detail? Especially the "disadvantages" part?
====

I then described my ('diluted') experiences.

After that you have systematically told me and others that our
experience in developing software is wasted because there is a "better
way", and that you know this for sure.

When we were (I was) finally motivated to investigate your claims
further, I discovered that my work coleagues who had previosly
investigated the 'Agile Way' had come to conclusions that I in turn
agree with... that Agile would not work well in *my* development
environment.

As far as I am concerned, this just proves my original assertions to be
100% accurate... what I originally said was:

'Agile Programming'... sure, it works, and it works well for some
people, but it is not for everyone, and you can get programs that work
just as well using other more traditional ways. Still, it has advantages
and disadvantages.

So, what is not true in the above statement?

Then, you asked me to describe my work environment (my experience with
Agile), which I obliged, and you took my response to be an opportunity
to point out 'flaws' in our systems, and to identify where I was
expressing 'myths' about Agile. This was after I was very clear to say
that I did not know the Agile manifesto, that my experience was
'diluted' and that other colleagues had been tasked with investigating
the strategy and had learned some lessons from it, and discarded others.
You used my response to launch an evangelical campaign for Agile
development disregarding our assertions that it can't always work that way.

From my perspective, it is clear that this all started with *you*.

Rolf




2009\02\23@083725 by olin piclist

face picon face
Vitaliy wrote:
>> You do, however, have to have a good idea
>> of the architecture before designing individual pieces.
>
> I agree with the statement, for reasonable values of "good".

In other words, it's a judegment call.  I think this is the main point we
have been trying to get accross.  There is no magic formula, only broad
guidelines.  Each case is different and you apply your knowledge and
experience to each to arrive at the best ballance as you see it.  Others
will want a different ballance because their knowledge and experience is
different.

> Just so
> we're not dealing with complete abstractions, think about the
> projects you've done. What was the maximum amount of time you ever
> spent on designing the architecture upfront, expressed as % of the
> total time spent on the project?

That's a good question but I don't have a good answer.  I know you hate
hearing this, but every project is different.  I recently had to add a major
feature to a software system I mostly wrote a year ago.  It ended up adding
about 1000 lines to the existing 8000 lines of code.  The actual coding and
testing took about 2 days I think.  I probably spent a few hours carefully
thinking out how I was going to do this since a number of constraints had to
be kept in mind and this was one of those cases where performance and
scalability were important.

This project was adding a network communications interface to existing
software.  I spent about a day up front designing the protocol and writing
this down in a spec.  This was all before I touched a single line of code
and before I spent the few hours thinking about the structure of the
implementation.  This was one of those cases where the external spec was
very important.  You can't have multiple people implementing a
communications protocol without everyone knowing exactly what every byte
means.  Of course there were a few changes and additions as implementation
progressed, but I always kept the document up to date.

When both sides were done and we tested them together, it took only about a
hour to figure out the problems and fix them.  I had accidentally sent 8
bytes in a place the spec said 7, and the other guy accidentally missed a
couple of bytes that the spec said were there.  Without a clear and detailed
protocol spec, this would have been a mess.  Even though I spent probably
1/3 of my time creating and maintaining the spec, it was well worth it for
this project and future projects which will probably have to connect to the
same server.

> I haven't worked on very large projects, but I have worked on
> projects that required several man-months to complete. At the
> beginning, we would spend maybe a day (3-5 hours) talking about the
> architecture, and specifying the details for the first iteration.
> This was followed by jumping right into implementation: putting
> together the schematic, prototyping the unproven areas, writing code.

Hmm.  Without knowing the details of this project I can't say whether I
think that was right or not, but in general that sounds rather thin for the
up front architecture.

On the projects I've done that took several people a few months, we would
probably work out the initial architecture in about the same time.  However,
that initial discussion would usually result in a few things that needed to
be determined before the architecture was ready enough for implementation
and detailed design.  These were questions the answers of which would make a
significant difference to the architecture such that starting design without
them would be pointless.  It wouldn't be unusual if some of the people spent
the next few days investigating these issues and evaluating alternatives
before the real design could begin.

> New things were learned during that time, so the following week we
> would make changes to the original plan, and do some more
> development. As the project progressed, certain things sort of just
> fell into place ("hey, we have room for the Bluetooth module
> connector, let's add it"). Talking about these things at the
> beginning would have meant making lots and lots of assumptions,
> because the necessary information was not available then.

But from your description it could just as easily have been "Too bad there
is no room for a Bluetooth module.  If we'd only thought about this up front
we could have arranged for it.  Now we either have to do without Bluetooth
or re-do a lot of the design.".

{Quote hidden}

But we're not taking it to the extreme.

> I think more in terms of cohesive, loosely coupled modules. The
> question then becomes: "can this feature be implemented?" down the
> road, not "how will it be implemented?"

The point I was trying to make was that when the "how" effects other
subsystems it is helpful to consider these tradeoffs up front.  PICs are
good examples of this.  Two different modules can't use timer 1, for
example, totally for their own purposes.  On PICs, that type of limited
resource allocation needs to be decided up front at a higher level, which
means the general architecture of the firmware has to be thought about.  If
not, you end up with strange bugs and have to re-write a lot of code.

> Then again, even if a wrong decision is made because we did not spend
> the time to follow every path, and did not consider every single
> detail, chances are it's cheaper to back up and make the necessary
> changes, than to do this sort of exhaustive planning upfront.

There you go again.  You keep characterizing what I'm saying as "exhaustive
planning upfront".  There is a lot of room between planning two weeks out
and then slapping something together and "exhaustive" planning.

> Just so we're clear -- yes, I do consider thinking about how you're
> going to implement button debouncing at the beginning of the project,
> is probably too much planning. I know that I need buttons, I know I
> need to allocate enough inputs, but I don't need to figure out how
> the function is going to work. I will deal with this problem, when I
> get there.

Then what mechanism do you have in place to ensure that the button debounce
code will fit in the same system nicely with other modules?  On small
resource-limited systems like PICs, you do have to consider these things up
front because the impact of the decisions are not limited to the scope of
the subsystem they apply to.

> Of course you need to plan ahead, beyond the next iteration. But you
> need to do only enough planning to do the next iteration. Does it
> still sound like a contradiction to you?

Yes.

> You only need to look at things that will affect the next iteration
> (including high-level architecture). If the parts are sufficiently
> decoupled, you don't need to worry about the design of module B,
> while you work on module A.

But they are often not suffciently decoupled.  I've already given a few
plausible PIC-related examples.

> I'm not saying you should not provide an estimate. But I think that
> you should honestly tell the customer that it is an educated guess
> based on the best information available to you at the time, and that
> most likely it is wrong.

Of course, but guess what 99% of all customers do.  No matter how much you
qualify your estimate and tell them all the contingencies that would cause
it to change, they hear the number and throw away everything else.

> I will say however, that there are consultants on this list that
> refuse to provide a fixed cost estimate (remember, several years ago
> I actually submitted an RFQ for an OBD-II gizmo?). They want to bill
> the customer on a T&M basis.

As do I, depending on the situation.  I am only willing to give a fixed
price quote when the job is well specified.  And yes, that had better be in
writing.  Unfortunately, some customers want a fixed price but see writing a
spec as wasted time.  Get out of there fast when you hear that.


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

2009\02\23@085212 by olin piclist

face picon face
Vitaliy wrote:
> It seems impossible to me that you can spend a whole year producing
> nothing but paper, and be better off than if a more iterative
> approach was used. At least I haven't misunderstood what you were
> saying. I think this kind of approach is totally wrong, but of course
> you're entitled to think "it was a good thing."  I'd be curious to
> know who Olin would side with, he recently said that he never argued
> for 100% design upfront.

We don't have enough information to make up our own minds so I'll take
Gerhard's word for it that it helped in his particular case.  It's quite
clear though that neither I nor Gerhard are saying this is the right
approach for all projects.  In fact our main point seems to be that every
project is different.  I can imagine projects where a year of up front
planning makes sense.  For the projects I've done so far that would have
been silly, but that doesn't make it silly in all circumstances.

> It's funny when people diss on certain aspects of lean development,
> and try to convince me that it cannot work -- when I used it, and it
> worked, and we as a company continue to use it with much success.

That's fine, but you are leaving out that it worked *in your cases*.  Your
fallacy is in extrapolating that to all cases.


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

2009\02\23@085548 by olin piclist

face picon face
Jake Anderson wrote:
>> So 'this' project requires 3 switches and 4 LEDs, but why shouldn't
>> the software interface for the module handling these allow for
>> expansion.
>
> Because adding the ability to expand it involves more work and bugs
> that may never be used in the finished product.
>
> If you want to expand it at a later date, then add the stuff to expand
> it then.

This is where the experience and skill of the architect matter.  This is of
course a tradeoff between what it costs to allow for the expansion now,
versus the cost of adding it to a system not designed for it times the
probability of that happening.


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

2009\02\23@130928 by Michael Algernon

flavicon
face
The largest project I ever worked on was a $2,000,000 electronic  
security system in 1980.  Such a system now would of course be more  
like 6 million dollars.

We did most of the work over a 9 month period.  Myself and a guy named  
Bob Linfield designed the architecture.  We met daily and discussed  
how the development was going.  He guided one group and guided  
another.  We were very successful and we added and changed things as  
we went.  Looking back, I felt the major factor leading to success was  
that was that 80% ( I made that number up ) of the participants were  
very good, very congenial, and very willing to exchange ideas.  There  
were no hidden agendas and when we agreed to do something , everyone  
stuck to the agreement.  This was a wonderful group.


In, contrast, I was contracted to help troubleshoot a project in  
Chicago in 1986 that was over-budget and late.  Most of the fix-it  
team concentrated on technical issues since that is what they liked to  
do.  I wandered around and asked lots of questions of everyone.  What  
I found was that the software group had a different goal than the  
mechanical group which had a different goal than marketing group which  
had a different goal than the manufacturing arm.  All the groups were  
very suspicious of me and other people in the project.  In particular,  
the manufacturing VP was ( in my mind ) literally playing a game with  
the rest of the project group.  He would ask them for final  
specifications knowing full well that they were not ready to provide  
them.  He would then buy materials and then castigate group members  
for being idiots because there were a lot of useless parts in  
inventory.  I hinted to management about what was happening ( I was  
kind of chicken ) and it got back to him.  I was accused of sexual  
harassment and shown the door.  Interestingly, the big cheese from  
London who hired me in the first place ( the project was being done by  
a division of a company based out of the UK ) flew into Chicago for  
some reason and while he was there he offered me a going away present  
of $5K.  He said he could not save my contract.  I presume he thought  
I had done something right.  6 months later the project was cancelled,  
the division president was fired and everyone went on to other things.

MA



WFT Electronics
Denver, CO   720 222 1309
" dent the UNIVERSE "

All ideas, text, drawings and audio , that are originated by WFT  
Electronics ( and it's principals ),  that are included with this  
signature text are to be deemed to be released to the public domain as  
of the date of this communication .

2009\02\23@230805 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> It seems impossible to me that you can spend a whole year producing
>> nothing but paper, and be better off than if a more iterative
>> approach was used. At least I haven't misunderstood what you were
>> saying. I think this kind of approach is totally wrong, but of course
>> you're entitled to think "it was a good thing."  I'd be curious to
>> know who Olin would side with, he recently said that he never argued
>> for 100% design upfront.
>
> We don't have enough information to make up our own minds so I'll take
> Gerhard's word for it that it helped in his particular case.  It's quite
> clear though that neither I nor Gerhard are saying this is the right
> approach for all projects.  In fact our main point seems to be that every
> project is different.  I can imagine projects where a year of up front
> planning makes sense.  For the projects I've done so far that would have
> been silly, but that doesn't make it silly in all circumstances.

It was Gerhard who said that authorities mean nothing to him, and I don't
see why I should take his word for it. It seems to me that even the largest
projects of the 20th century -- the Manhattan project, and the Apollo
project are two good examples -- followed a much more "hands-on", iterative
approach. The limiting factor is human ability to comprehend and retain
information, so even if the project takes 10 years to implement, I don't see
why it makes sense to spend 1 year producing nothing but documentation.


>> It's funny when people diss on certain aspects of lean development,
>> and try to convince me that it cannot work -- when I used it, and it
>> worked, and we as a company continue to use it with much success.
>
> That's fine, but you are leaving out that it worked *in your cases*.  Your
> fallacy is in extrapolating that to all cases.

You're either misreading what I wrote, or reading too much into it. I said
above that when people tell me that certain aspects of Agile don't work
(=never work, are stupid, involve the Star Trek "Force", etc) they are
clearly wrong because I used them, and they worked for me (and for other
people).

Vitlaiy

2009\02\23@231248 by Vitaliy

flavicon
face
Rolf wrote:
> Then, you asked me to describe my work environment (my experience with
> Agile), which I obliged, and you took my response to be an opportunity
> to point out 'flaws' in our systems, and to identify where I was
> expressing 'myths' about Agile. This was after I was very clear to say
> that I did not know the Agile manifesto, that my experience was
> 'diluted' and that other colleagues had been tasked with investigating
> the strategy and had learned some lessons from it, and discarded others.
> You used my response to launch an evangelical campaign for Agile
> development disregarding our assertions that it can't always work that
> way.
>
> From my perspective, it is clear that this all started with *you*.

Yes Rolf, it has been my hidden agenda all along to wage my evangelical
campaign, and I jumped at the chance when you mentioned the word "Agile".

You have convicted me, I have been completely discredited.

Vitaliy

2009\02\23@232410 by William \Chops\ Westfield

face picon face

> It seems impossible to me that you can spend a whole year producing  
> nothing but paper

The whole "document things first" is predicated on the idea that  
producing documentation is easier than producing code.  That doesn't  
seem to universally true, especially if you're doing something new  
enough that you actually have to try things out.  One of the biggest  
problems with up-front documents is that they tend not to be changed  
or updated to reflect realities that don't become apparent until after  
coding started...

BillW

2009\02\24@021850 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>>> You do, however, have to have a good idea
>>> of the architecture before designing individual pieces.
>>
>> I agree with the statement, for reasonable values of "good".
>
> In other words, it's a judegment call.  I think this is the main point we
> have been trying to get accross.  There is no magic formula, only broad
> guidelines.

I agree that in the end, deciding how much planning is necessary is a
judgement call. That's what makes a project different from changing a tire:
there's uncertainty, and no clearly defined way. If this weren't true, we
could have computers write software for us.

However, it helps to have some guidelines when making this judgement call.
As I said before, I believe that specifying the implementation details of a
feature months in advance is generally a bad idea. The guideline I use (for
the umpth time) is "enough details for one iteration". I don't know how else
to explain it, it doesn't mean you just think one or two weeks ahead, you
can look a year ahead. You just don't get bogged down in details that do not
matter for the next iteration.


> Each case is different and you apply your knowledge and
> experience to each to arrive at the best ballance as you see it.  Others
> will want a different ballance because their knowledge and experience is
> different.

This is one fundamental difference in the way we think about projects. I do
not see every project as completely unique. If you're doing something
completely different every time, you're doing pure research, not project
development. If every project is truly unique, your prior knowledge and
experience are irrelevant. This is obviously not the case: projects share
similar features, and some things are always true, therefore you can apply
prior experience to new projects.

For example, I think everyone agrees that the most important factor in
project development is the human element. You need great people if you want
to accomplish great things. You can't say that this is true in some cases,
but not others.

Other factors are not as certain, but software development has been around
long enough for patterns to emerge. We call our discipline "Computer
Engineering" for a reason.


{Quote hidden}

I have no problem whatsoever with this approach. What you did could easily
fit in one iteration, and it sounded like you spent your time defining only
things that you needed for the immediate future.


{Quote hidden}

I don't see a contradiction here, we often do the same thing.


{Quote hidden}

I guess I should have mentioned that Bluetooth was optional. :) We had a few
hard requirements, and several "options".

I can't think of a good example, but most of the time initially it seems
that there are many alternatives. It is possible to spend a lot of time
arguing about the merits of each alternative, but these alternatives have a
way of eliminating themselves as the project progresses. So whenever we get
stuck arguing about which way to go, it is usually because the alternatives
are very similar and it doesn't really matter which one we choose. So we
tentatively pick one alternative, and start implementing it. If it works,
great. If it doesn't, we learned something and can now make a better
decision based on this new information.


>> Taken to the extreme, this can lead to paralysis by analysis.
>
> But we're not taking it to the extreme.

Good for you. Based on your description of the way you approach projects, it
really doesn't sound that different from the way we do things. It seems to
me that the differences of opinion are based on speculation ("I've never
spent a whole year doing nothing but writing specs, but I see how it *could*
be necessary.")


{Quote hidden}

In our most recent projects, we opted out for using a hardware timer to
increment a counter, and using functions similar to clock() and diff(). So
I'm never writing to the timer, I'm just reading from it.

We're also using intermediate objects that manage shared resources. Yes, you
can do it on a PIC, as long as it's running at 40 MIPS. :)


>> Then again, even if a wrong decision is made because we did not spend
>> the time to follow every path, and did not consider every single
>> detail, chances are it's cheaper to back up and make the necessary
>> changes, than to do this sort of exhaustive planning upfront.
>
> There you go again.  You keep characterizing what I'm saying as
> "exhaustive
> planning upfront".  There is a lot of room between planning two weeks out
> and then slapping something together and "exhaustive" planning.

Olin, calm down. :) I wasn't talking about you, personally.


{Quote hidden}

We're using a higher level PIC where we have the luxury to do this sort of
thing. The thing about lower end PICs is that you are closer to the metal,
but at the same time the projects are also less complicated (you can only
fit 2K of code, in 2K of ROM).


>> Of course you need to plan ahead, beyond the next iteration. But you
>> need to do only enough planning to do the next iteration. Does it
>> still sound like a contradiction to you?
>
> Yes.

I'm sorry Olin, I need a little more feedback than that. I honestly don't
know how else to explain it, because I don't understand which part you don't
get.


>> You only need to look at things that will affect the next iteration
>> (including high-level architecture). If the parts are sufficiently
>> decoupled, you don't need to worry about the design of module B,
>> while you work on module A.
>
> But they are often not suffciently decoupled.  I've already given a few
> plausible PIC-related examples.

Then by jolly, consider how the modules will interact. My point is that it's
impractical to consider *everything* unless you do some actual coding
in-between. It would be a waste of time, because you can verify many
assumptions, and make the decisions while you're writing code.


>> I'm not saying you should not provide an estimate. But I think that
>> you should honestly tell the customer that it is an educated guess
>> based on the best information available to you at the time, and that
>> most likely it is wrong.
>
> Of course, but guess what 99% of all customers do.  No matter how much you
> qualify your estimate and tell them all the contingencies that would cause
> it to change, they hear the number and throw away everything else.

I feel for you. :)

This is why I think customers would be better off if they understood the
benefits of lean development. Everyone would be better off if we
acknowledged the presence of the elephant in the room (changing
requirements, and the inherent uncertainty of projects), and deal with the
elephant instead of pretending it isn't there. I know that most customers
prefer to continue to live in La-La Land, and expect 100% accurate specs and
100% accurate cost & time estimates.


{Quote hidden}

I think I will see what it is like to be in your shoes, soon enough. :)

Vitaliy

2009\02\24@022451 by Vitaliy

flavicon
face
William "Chops" Westfield wrote:
>> It seems impossible to me that you can spend a whole year producing
>> nothing but paper
>
> The whole "document things first" is predicated on the idea that
> producing documentation is easier than producing code.  That doesn't
> seem to universally true, especially if you're doing something new
> enough that you actually have to try things out.

I don't think writing documentation is easier than writing code. I certainly
prefer the latter.


> One of the biggest
> problems with up-front documents is that they tend not to be changed
> or updated to reflect realities that don't become apparent until after
> coding started...

True. Also, if you think about it, if you have docs describing a part that's
not going to be implemented for some time, the time spent updating this
section in the docs to reflect the changes in other parts of the document,
is essentially wasted. Why not write it when it's actually needed?

Vitaliy

2009\02\24@023636 by Vitaliy

flavicon
face
Jake Anderson wrote:
> Because adding the ability to expand it involves more work and bugs that
> may never be used in the finished product.
>
> If you want to expand it at a later date, then add the stuff to expand
> it then.

Jake, thanks. I'm becoming more and more conviced in the validity of the
YAGNI principle. Designing functionality that you *think* you're going to
use, is usually a waste of time.

Recently, we were going over the specs of a project where we added
provisions for a feature that is not going to get implemented (because in
the months since, we found a better way). However, pins were allocated and
traces were run -- so now we have to scrap the old boards, or cut the traces
to make the design fit the new way of doing things. In retrospect, we should
have simply left the pins unconnected, until we figured out exactly how this
feature would be implemented.

When you add provisions for "future expansion", you have to write, debug,
document, and maintain the code. Recently I started doing something that
would have been anathema to me two years ago: I actually started *removing*
unused features because I realized that their presence in the project is not
free.

Vitaliy

2009\02\24@055027 by Jake Anderson

flavicon
face
Vitaliy wrote:
> Jake Anderson wrote:
>  
>> Because adding the ability to expand it involves more work and bugs that
>> may never be used in the finished product.
>>
>> If you want to expand it at a later date, then add the stuff to expand
>> it then.
>>    
>
> Jake, thanks. I'm becoming more and more conviced in the validity of the
> YAGNI principle. Designing functionality that you *think* you're going to
> use, is usually a waste of time.
>  
Its easy, just think "what are we getting paid for"
Its a hot water heater, provided hot water comes out the pipe every time
they turn the tap that's all the customer really wants.
Make that bit work really well, then when your programmers want some
"fun time" let them implement the LCD interface with some spare pins.

I'm having that problem at the moment, Looking for a barcode inside a 10
megabyte text file on a PDA in python. I wound up writing my own binary
search algorithm because it was the only thing that fitted in the
devices memory. My first version would do 0.6 lookups per second. Its
now up to 9.7 lookups per second and I keep having ideas on how to make
it fast enough by doing fancy indexes and the like. I have to force my
self to concentrate on getting the bit that uses that lookup to put
stuff on the screen then send that back to base.

I want to make it faster and i could, but its not worth it.

> Recently, we were going over the specs of a project where we added
> provisions for a feature that is not going to get implemented (because in
> the months since, we found a better way). However, pins were allocated and
> traces were run -- so now we have to scrap the old boards, or cut the traces
> to make the design fit the new way of doing things. In retrospect, we should
> have simply left the pins unconnected, until we figured out exactly how this
> feature would be implemented.
>  
Its not an either/or thing, how much "additional functionality" you
build into something should be related to how hard it is to add it later.
IE in small software projects (ones with one primary developer) then
adding features that involve 4 different modules isn't paticularly hard,
so do just the minimum to get it right and bug free. With hardware its a
bit harder, as such make provision for adding bits later on, but perhaps
don't "pretend implement" it, just bring the pins out to some headers or
some such.
> When you add provisions for "future expansion", you have to write, debug,
> document, and maintain the code. Recently I started doing something that
> would have been anathema to me two years ago: I actually started *removing*
> unused features because I realized that their presence in the project is not
> free.
>
> Vitaliy
>
>  
I hope you wind up with a project that does the job its sposed to do far
better as a result.

2009\02\24@061416 by Rolf

face picon face
Vitaliy wrote:
> Yes Rolf, it has been my hidden agenda all along to wage my evangelical
> campaign, and I jumped at the chance when you mentioned the word "Agile".
>
> You have convicted me, I have been completely discredited.
>
> Vitaliy
>
>  
Whew.

At least we cleared that up.. Feel much better now. ;-) For a while I
thought this was an intellectual, not religious debate, and I just had
to be certain.


Rolf

2009\02\24@065346 by Jake Anderson

flavicon
face
Rolf wrote:
> Vitaliy wrote:
>  
>> Yes Rolf, it has been my hidden agenda all along to wage my evangelical
>> campaign, and I jumped at the chance when you mentioned the word "Agile".
>>
>> You have convicted me, I have been completely discredited.
>>
>> Vitaliy
>>
>>  
>>    
> Whew.
>
> At least we cleared that up.. Feel much better now. ;-) For a while I
> thought this was an intellectual, not religious debate, and I just had
> to be certain.
>
>
> Rolf
>  
You two do realise you have been in violent agreement for the past week
or 2 right?
(well up until you got narky with each other over who said what teensy
slight when and with which mis quote ;-P)

2009\02\24@070000 by olin piclist

face picon face
> =never work, are stupid, involve the Star Trek "Force", etc

Star Trek had warp drive, the transporter, and Klingons, but it was Star
Wars that had "the force".  Geesh, if you can't even keep important stuff
like this straight, I can't believe anything you say about software weenies
and how to get them to do any work  ;-)


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

2009\02\24@075950 by Rolf

face picon face
Jake Anderson wrote:
>>  
>>    
> You two do realise you have been in violent agreement for the past week
> or 2 right?
> (well up until you got narky with each other over who said what teensy
> slight when and with which mis quote ;-P)
>  


Really? I must have missed something. Seriously, no sarcasm now.

I thought the issue was that Vitaliy claims Agile programming works
well, and 'everyone else' claims that there may be times that Agile
works well, but there are other times when other 'methodologies' are better.

I think people (me) are getting frustrated by Vitaliy's insistence that
(paraphrasing) "if we only understood Agile we would see the light and
realize it is always the best thing".

I think our (my) response is that "that's absurd, I have a situation I
work in right now where multiple intelligent, experienced people have
evaluated Agile methods, and decided, after reasonable consideration,
that it is not ideal for us. Other methods will get the job done 'better'".

I think that what might pass for 'violent agreement' is that, taken in
some contexts, the various Agile methods do make sense. The issue,
subtle though it might appear, is that 'some contexts' are not 'all
contexts' like Vitaliy would have us believe.

Unfortunately, like many debates with subtle points, the emotional side
of things heats up before the subtlety can be expressed, and hence the
debate melts down in to a bun-fight on the peripheral concepts which, in
the long run, are meaningless.

From my side the 'debate' lost it's fun when it became apparent that
the issues are not being communicated effectively. The core of the issue
is the 'universal nature' of Agile, and it is apparent that Vitaliy is
not willing to concede this point. Thus, we end up in a stale-mate where
a bunch of words are bandied around but no-one is resolving anything
because the real issue is not being addressed.

Hmmm... perhaps it is time to step away from the debate and just move on.

Rolf

P.S. Thanks Jake, and welcome to the debate ;-)

2009\02\24@080156 by Rolf

face picon face
Olin Lathrop wrote:
>> =never work, are stupid, involve the Star Trek "Force", etc
>>    
>
> Star Trek had warp drive, the transporter, and Klingons, but it was Star
> Wars that had "the force".  Geesh, if you can't even keep important stuff
> like this straight, I can't believe anything you say about software weenies
> and how to get them to do any work  ;-)
>
>
>  
Hi Olin, what message was this in response to? I must have missed it
somewhere...

Rolf

2009\02\24@082701 by olin piclist

face picon face
Vitaliy wrote:
> I have no problem whatsoever with this approach. What you did could
> easily fit in one iteration, and it sounded like you spent your time
> defining only things that you needed for the immediate future.

Not entirely.  I put a lot of thought into the protocol to allow for future
expansion in directions yet to be dreamed up.  This included simple things
like extra flag bits, optional data fields with opcodes in their own
namespace, more bits than immediately needed in enumerated fields, etc.  But
the structure of the protocol itself was also influenced by thinking ahead
and not just designing for the immediate problem.  That's a bit harder to
describe without getting into specifics, which I can't since this is
proprietary to a particular customer.

Of course there is always a tradeoff between the cost of hooks and expansion
that are a burden in the short term and may never get used, versus the cost
of having to make major uncomfortable changes in the future.  In this case
the extra burdens are pretty minimal, but only time will tell if I left
enough provisions for future needs.

I probably could have done the protocol part in half a day instead of a full
day if I was just trying to solve the immediate problem.  I'm pretty sure
that would cause trouble within a few months, but of course can't prove that
now.  This is the kind of planning I'm talking about that looking only at
the next iteration won't get you, yet I am quite convinced it will have been
the right thing to do in the long run.

{Quote hidden}

I think it's finally dawning on me where you're coming from.  Please
understand this is not meant as a insult, but your description above shows
you don't have a project architect on staff.  Worse, you presonally don't
see the need for one nor fully understand what one can do, probably because
you've never been exposed to that.  This is the way you've always done
things, so it feels normal.  In fact, the more I think about it I realize
that most of what you are advocating, and apparently a lot of Agile (based
only on heresay from this thread), are mechanisms for dealing with the
absence of architect-level oversight of projects.

Your description of "Oh look, Bluetooth fits" is a great example.  Yes, you
said Bluetooth was optional.  However if I had been at the initial meeting
and you said Bluetooth was optional, I would not have let it slide.  I would
have asked a bunch of questions like "What is the purpose of Bluetooth?",
"How would the customer use it?", "In what situations?", "In what way does
it make it easier/better for the customer?", "How often do these reasons
apply?", "How much more do you think you could sell a unit with Bluetooth?",
"... with the ability to add Bluetooth later?", "How many of each
with/without do you think you could sell?", etc, etc.  Sure, some of these
require guesses on your part, but that's really no different from the
guesses you are making to develop the product in the first place.  You
already have the answers, but don't want to confront the questions because
this sort of planning it outside your confort zone.  My job is to get the
information out that you already have in your head, separate out whatever
emotional issues may be attached (I'm not saying in this case, but in the
general case this is more common than you may imagine), and make you
confront the tradeoffs logically.  I guide the process, add engineering
facts and analisys as needed, but it's mostly getting the answers that are
already in your head even though you don't know it.

As a result of this discussion and analisys, we would have a plan to make a
stripped down product and screw Bluetooth, make a whizbang product with
built-in Bluetooth, make it field upgradable, a manufacturing option, two
products, or whatever.  This could all have been rationally decided with the
information you already had.

Of course I understand external things can change which might force a change
in strategy.  A competitor might come out with a particular point product, a
well publisized virus gets spread via Bluetooth and suddenly it gets a bad
name, or whatever.  These are unforseeable things you deal with as they come
up.  However, discovering Bluetooth fits into the design partway thru is not
one of them.  That should have been forseeable and planned on one way or the
other.  A good architect would not have let you slide on this.

Again, I strongly suspect you have no project architect, probably haven't
experienced a project with one, and therefore don't really understand what
one does and how that would effect the project.  I also want to point out
again I really don't mean this as a insult in any way.  Good architects seem
to be quite rare.  Even most good engineers don't make good architects.  It
also requires a considerable minimum of experience.  You need to have been a
good engineer for at least 10 years before you can start doing architecture,
and probably another 5 years minimum after that before you can be a good
architect.  I probably would be uncomfortable with anyone in a architecture
role that didn't have 20 years of relevant experience.

So given that good architects are rare and therefore most projects don't
have one, it makes sense that a set of project management guidelines evolve
that are effective means of dealing with this reality.  I think what you are
describing, and apparently what Agile and other "light" strategies have
tried to codify are such guidelines.  In that light, they make a lot more
sense to me than when you first described them.  I wonder if the apostles of
Agile realized this or not.  Probably is not.

> In our most recent projects, we opted out for using a hardware timer to
> increment a counter, and using functions similar to clock() and diff().
> So I'm never writing to the timer, I'm just reading from it.
>
> We're also using intermediate objects that manage shared resources.
> Yes, you can do it on a PIC, as long as it's running at 40 MIPS. :)

This sounds like you're spending real $$, some of which may have been
avoidable with better project planning and guidance at the architecture
level.

> This is why I think customers would be better off if they understood the
> benefits of lean development.

Perhaps, but all too many don't understand development of any kind, and
don't want to.  That's why they hire out the project to someone that can
magically make it all happen for them.


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

2009\02\24@083709 by Jake Anderson

flavicon
face
Rolf wrote:
{Quote hidden}

I think what it boils down to is you like waterfall with agile elements,
He likes agile with some waterfall elements (though probably further to
the agile end of the spectrum).

Most of the other stuff you two seem to have been saying is nit picking
over details.
I'm going to skip over weasel words here (like seem and apparently)
because everybody knows this is opinion and I think you are both right
so deal with it mmmkay ;->

In theory pure agile and pure waterfall both work. In practise neither
approach will work for all applications. You both agree with that.
IE pure waterfall doesn't make sense in an environment with 2
programmers and a total project life of 3 weeks.
Pure agile wont work when you have 400 programmers and a project that's
got a life cycle of 10 years.

You (Rolf) come from the 400 programmers side of the game and as such
have less use for agile as an upper level tool, you can use its elements
for achieving specific goals but you need the organisation that
waterfall provides to actually make progress with large teams, long time
spans, and an absence of "brain space" IE your programmers can't be
expected to hold a decent % of the project in their mind to know how
things they do will affect other things.

Vitaliy is coming from the other end of the spectrum, from his POV large
amounts of documentation just get in the way rather than enable
progress. As such he can use agile for a much larger portion of his
total project. He still needs some waterfall elements most likely in
order to deal with customers in a way they are happy with, but by in
large the projects will fit into the heads of the people doing it, so
documentation and rigid design slow down the ability to solve problems,
by just fixing them rather than doing change analysis.





2009\02\24@092550 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Gerhard Fiedler wrote:
>> The whole thing started, IIRC, with you saying that some things
>> changed profoundly in the software development world with the Agile
>> Manifesto,
>
> Never ever have I said that.

>From one of your earlier posts (in "[TECH] Agile programming (was Re:
[P|C] Banksel)"):

:: The only thing that changes with Agile, is how you approach software
:: development.

You said that how software development is approached (in general, that
is, in the software development world) changes with Agile. How is this
different from how I paraphrased you?

:: Agile addresses two big fallacies with project management: (1) men
:: and months are interchangeable and (2) requirements never change.

This says that these two fallacies are "big", which I read that they are
also frequent, and that something WRT these two fallacies (again, not in
your company, but in software development in general) changed with
Agile.


>> I also think that the Agile world is full of good things to read and
>> consider -- and also full of crap.
>
> I won't waste my breath trying to convince you that Agile is not full
> of crap; you've made up your mind. If someone else wants to find out
> what Agile is, the information is out there.

I've given a few examples of (IMO) crap that's there for everybody to
see.

Video being described as "more efficient" than written material is one
thing. Maybe for one from the video clip generation who hasn't learned
to read enough to be able to make use of an index or a text-based
search, but anybody with decent reading skills can understand the
contents of almost anything analytic and non-trivial that's in written
form in a fraction of the time it takes to watch a video representation
of it. It's a bit more intense work (you can't just lean back and let
the presentation pass by), but then... if you want to lean back and let
things pass by, you shouldn't be in my team to start with.


> It's funny when people diss on certain aspects of lean development,
> and try to convince me that it cannot work

Who said that it cannot work? You really should avoid trying to defend
what hasn't been attacked.

>> But this can't really be extrapolated to the software development
>> world at large.
>
> I never said that Agile had a profound impact "on the software
> development world at large."

Not in these words, but you did (see above).

> In fact, I said many times that the knowledge was out there long
> before the Agile Manifesto. Which contradicts your (and Olin's)
> notion that every project is different, and therefore there can be no
> rules.

There are overall more or less useful guidelines (like some of the
phrases in the Agile Manifesto), but every rule has a valid range of
situations -- and there are situations that are outside of it.
Acknowledging this is (part of) what makes a decent manager, and knowing
the limitations of the rules is (part of) what makes a good one. IMO.
This is what your mother never told you about the Agile Manifesto :)

Gerhard

2009\02\24@092550 by Gerhard Fiedler

picon face
Vitaliy wrote:

> Olin Lathrop wrote:
>>> It seems impossible to me that you can spend a whole year producing
>>> nothing but paper, and be better off than if a more iterative
>>> approach was used. At least I haven't misunderstood what you were
>>> saying. I think this kind of approach is totally wrong, ...

Nobody else has considered any of your approaches "totally wrong", and
without knowing the details of the situation, are you really sure you
are in a position to be able to make such a judgment?

FWIW and IMO, this is something a manager (specifically) shouldn't do.
Ask first, to get all the relevant details from all involved, before
letting your feeling of discontent being known.


>>> More information about the nature of the project would have been
>>> useful.

I've described some aspects of this project here and there.

>> We don't have enough information to make up our own minds so I'll
>> take Gerhard's word for it that it helped in his particular case.  

Yup. It was a billing system for an insurance company, where the
knowledge of the details of literally thousands of billing procedures
were spread out over several departments, in a mix of what some
individuals know and what was partially (and not always correctly and
consistently) documented in several not related documents of the
different departments. A huge mess, with thousands of special cases and
odd rules. Without getting a good overall picture of all requirements,
there was no way that could have been started reasonably. To get it took
a few people (not programmers) over a year. The programming was then
done in about 18 months, with a team that started out at around fifty
and towards the end got thinned down, towards the final maintenance
staff. We were using some lean elements in the project management (I was
responsible for overall coordination, project procedures, making sure
everybody knows what she's supposed to do and does it, and the like),
but nevertheless I consider the extensive requirements gathering phase
prior to starting the development as very important in this case.

While there were regular interim releases to client reps during the
development, none of these had any business value, as the billing system
itself only had business value if it worked completely. Using any system
different from what they used before required a change of billing
procedures. Doing this in incremental steps would have been tremendously
expensive (creating a plan for the transition, training of all involved,
dealing with initial mistakes after changing procedures, to name just a
few cost drivers). There was no use in changing the procedures in place
at the time towards something "incremental" (which would have been
required if the incremental results would have been used in production).
So the procedures were only changed once the whole system was ready for
production -- which means that none of the incremental releases had any
business value.

This is not such a rare situation. It is quite common that any change of
procedures is complex, expensive and error-prone, so it doesn't make
sense to do this incrementally.


>> It's quite clear though that neither I nor Gerhard are saying this is
>> the right approach for all projects.  In fact our main point seems
>> to be that every project is different.  I can imagine projects where
>> a year of up front planning makes sense.  For the projects I've done
>> so far that would have been silly, but that doesn't make it silly in
>> all circumstances.
>
> It was Gerhard who said that authorities mean nothing to him,

That's not what I said. What I've been saying is something along the
lines of "learn from them, and apply what you learn using your judgment,
considering the specific situation". That's quite different.

It is actually you who is saying that the authorities that created the
waterfall model mean nothing to you. They are just as authoritative as
the ones who created the Agile Manifesto; the only thing that separates
them in terms of being "authority" is personal judgment (you consider
the ones authoritative but not the others).


> You're either misreading what I wrote, or reading too much into it. I
> said above that when people tell me that certain aspects of Agile
> don't work (=never work, are stupid, [...]

Who did ever say that aspects of Agile never work or are stupid? What
people have said is that there are situations that are outside of almost
every rule, and to know the rule includes to understand the limitations
of it.

You like science analogies. This is just as with "Ohm's Law". It's a
useful approximation of reality for the beginner and as long as you know
you are in a situation where it is valid, but it is only valid inside
the linear range of a real-world component. While it's possible to
design a circuit with ideal resistors (that represent "Ohm's Law"
without limitations), when you design a real-world circuit you'll have
to work with real-world resistors and other components that have
non-linearities; operational regions where "Ohm's Law" isn't valid.
Depending on the situation, there are several ways to deal with that;
usually you'd use a differently spec'ed resistor so that it stays within
its linear region over all relevant operational situations, but
occasionally you want to use specifically the non-linear region for some
special effect or you don't care that you're in the non-linear region.
So you better know where "Ohm's Law" is valid and where and why not --
knowing this is part of knowing the rule. This is not that different
with management rules.

Gerhard

2009\02\24@093436 by Gerhard Fiedler

picon face
Michael Algernon wrote:

> I felt the major factor leading to success was that was that 80% ( I
> made that number up ) of the participants were very good, very
> congenial, and very willing to exchange ideas.  There were no hidden
> agendas and when we agreed to do something , everyone stuck to the
> agreement.  

That's indeed a major factor. Especially the absence of hidden agendas.


> In particular, the manufacturing VP was ( in my mind ) literally
> playing a game with the rest of the project group.  

It is stuff like this that is tremendously important for the success of
a project that doesn't really show up in the normal project management
discussions. It's as if the participants were always good-intentioned
and the only thing missing is the right management framework. But being
able to deal with such realities (or recognize them before committing to
anything and stay out, if this is an option) is a major contributor to
project success. It seems that if not all then many big projects
involving several departments of a big company have something like this
going on, so it's not really a negligible factor.

Gerhard

2009\02\24@171512 by Vitaliy

flavicon
face
Olin Lathrop wrote:
>> =never work, are stupid, involve the Star Trek "Force", etc
>
> Star Trek had warp drive, the transporter, and Klingons, but it was Star
> Wars that had "the force".  Geesh, if you can't even keep important stuff
> like this straight, I can't believe anything you say about software
> weenies
> and how to get them to do any work  ;-)


Bad my is. Too much Kool Aid drank I have.

Vitaliy

2009\02\25@013140 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
[insurance billing story]

Thanks for the info, Gerhard. OK, I won't make any judgements because I've
never worked on projects of this scope. I have, however, read about similar
projects which were done by Agile teams.


> It is actually you who is saying that the authorities that created the
> waterfall model mean nothing to you. They are just as authoritative as
> the ones who created the Agile Manifesto; the only thing that separates
> them in terms of being "authority" is personal judgment (you consider
> the ones authoritative but not the others).

Sorry Gerhard, but the statement above clearly demonstrates that you are
full of it. Name *one* authority that created the waterfall model.

>From Wikipedia:
"The first formal description of the waterfall model is often cited to be an
article published in 1970 by Winston W. Royce (1929-1995),[1] although Royce
did not use the term "waterfall" in this article. Ironically, Royce was
presenting this model as an example of a flawed, non-working model (Royce
1970). This is in fact the way the term has generally been used in writing
about software development - as a way to criticize a commonly used software
practice."


>> You're either misreading what I wrote, or reading too much into it. I
>> said above that when people tell me that certain aspects of Agile
>> don't work (=never work, are stupid, [...]
>
> Who did ever say that aspects of Agile never work or are stupid? What
> people have said is that there are situations that are outside of almost
> every rule, and to know the rule includes to understand the limitations
> of it.

You don't need to dig deep, just read Rolf's creative critique of the agile
principles.


Vitaliy

2009\02\25@014716 by Vitaliy

flavicon
face
Gerhard Fiedler wrote:
>> Gerhard Fiedler wrote:
>>> The whole thing started, IIRC, with you saying that some things
>>> changed profoundly in the software development world with the Agile
>>> Manifesto,
>>
>> Never ever have I said that.
>
>>From one of your earlier posts (in "[TECH] Agile programming (was Re:
> [P|C] Banksel)"):
>
> :: The only thing that changes with Agile, is how you approach software
> :: development.
>
> You said that how software development is approached (in general, that
> is, in the software development world) changes with Agile. How is this
> different from how I paraphrased you?

Radically different. *When you* start using Agile, how *you* approach
software development changes. If *you* start using Agile tomorrow, *your*
approach will change tomorrow. I did not make a general statement, I simply
noted the impact of lean development practices on the individual adopting
the practices.


{Quote hidden}

You keep covering your ears, and screaming "AGILE IS CRAP BECAUSE VIDEO IS
BAD DOCUMENTATION!". All the while, the title and the content of the article
you are referring to, remains "Communication" (can _you_ read, Gerhard?
"Communication", not "documentation"). To most people, it is obvious that a
video conference is a more efficient way to communicate, than passing on a
spec.


>> It's funny when people diss on certain aspects of lean development,
>> and try to convince me that it cannot work
>
> Who said that it cannot work? You really should avoid trying to defend
> what hasn't been attacked.

I refer you once again to Rolf's attempt at agile comedy. And to be fair, to
some of your and Olin's posts as well.


> There are overall more or less useful guidelines (like some of the
> phrases in the Agile Manifesto), but every rule has a valid range of
> situations -- and there are situations that are outside of it.
> Acknowledging this is (part of) what makes a decent manager, and knowing
> the limitations of the rules is (part of) what makes a good one. IMO.
> This is what your mother never told you about the Agile Manifesto :)

Let's keep our mothers out of this, please. :)

Vitaliy

2009\02\25@023158 by Vitaliy

flavicon
face
Olin Lathrop wrote:
> Not entirely.  I put a lot of thought into the protocol to allow for
> future
> expansion in directions yet to be dreamed up.  This included simple things
> like extra flag bits, optional data fields with opcodes in their own
> namespace, more bits than immediately needed in enumerated fields, etc.
> But
> the structure of the protocol itself was also influenced by thinking ahead
> and not just designing for the immediate problem.  That's a bit harder to
> describe without getting into specifics, which I can't since this is
> proprietary to a particular customer.
>
> Of course there is always a tradeoff between the cost of hooks and
> expansion
> that are a burden in the short term and may never get used, versus the
> cost
> of having to make major uncomfortable changes in the future.  In this case
> the extra burdens are pretty minimal, but only time will tell if I left
> enough provisions for future needs.

I see.


> I probably could have done the protocol part in half a day instead of a
> full
> day if I was just trying to solve the immediate problem.  I'm pretty sure
> that would cause trouble within a few months, but of course can't prove
> that
> now.  This is the kind of planning I'm talking about that looking only at
> the next iteration won't get you, yet I am quite convinced it will have
> been
> the right thing to do in the long run.

The project you described (8000 lines of code, 1000 lines of code added)
actually sounds roughly like the project I'm working on right now. I will
soon be refactoring the code to fit a paradigm that wasn't apparent to me
several months ago, when we originally designed the framework. I could not
have known back then what I know now, because in the interim I worked on a
different project where I gained some experience and insight that I did not
have before.

We knew back then that there will be certain features that would need to be
added, down the road. These are the features that we will be adding right
after I'm done refactoring. If I added provisions for these features several
months ago, I would have had to scrap them because they would not fit the
way things are done now. So the effort would have been wasted.

You can chuckle if you want, but to me this is what "maximize the amount of
work not done" is about.


{Quote hidden}

Olin, I don't feel insulted a single bit. Especially because most of your
assumptions are wrong. :)

I said already, that I learned about Agile barely two years ago. This is not
the way I've always done things (we founded our company in 2002). I guess I
should say that at first, we did things the way that "made sense", which in
retrospect, bears strong resemblance to lean development. Then we decided to
do development "by the book", putting a lot of emphasis on upfront design
and documentation. Two projects died (were never completed) as a result.
Since I learned about Agile, and we started applying the concepts, we have
launched several successful products.

You're right, we don't have anyone with the official sounding title of
"Chief Architect" or any kind of "architect", for that matter. This doesn't
impede our ability to design and launch products that people buy.


{Quote hidden}

This is the project in question:

http://www.ecusims.com

If you look at the photo of the main board, you will see the spot where the
Bluetooth module (STM4100) goes. As you can see, it's merely a header.

Our original goal was to put together an ECU simulator as quickly as
possible, because we knew it would be a hot item.

We could have spent weeks agonizing over the details, but we chose not to --  
because our time is limited, and engineering makes money only when it
creates value for the customer. Most customers don't expect to see a
Bluetooth module in an ECU Sim, they are interested in its primary functions
(read the knobs, simulate OBD messages). But we saw that adding Bluetooth
would essentially be free, so we dropped it in. Then we saw that
multiplexing the plug-in modules would be a piece of cake, so we added two
more PIM sockets, and the switch and an LED tower to go with them. UART over
USB sounded like a no brainer, so it ended up on the main board as well.

We kept making changes to the design, adding improvements here and there,
long after the first release. We're up to revision H now, and we can't build
these things quickly enough. Feel free to guesstimate what the cost of the
parts is, then look at the price, and figure out what the profit margin is
on this thing.


{Quote hidden}

I don't subscribe to the notion that experience can be measured in years.
I've worked with enough different people to know that some programmers are
still idiots at 60 (no matter what their resume or references say to the
contrary). There are plenty of examples where great projects were led by
young people. And, of course, vice versa.


{Quote hidden}

Agile Manifesto was put together by people with many decades of experience,
who are considered (by many) to be experts in their field. So your argument
holds no water.


{Quote hidden}

We're spending maybe $3 more in hardware, but the savings in going from an
8-bit PIC to a 16-bit PIC in terms of programming effort, are tremendous.
When the difference in hardware cost starts to matter (i.e., when we reach
volumes of >1M) we will hire you to recode the whole thing in assembler, on
a 16F. :-))))


>> This is why I think customers would be better off if they understood the
>> benefits of lean development.
>
> Perhaps, but all too many don't understand development of any kind, and
> don't want to.  That's why they hire out the project to someone that can
> magically make it all happen for them.

Customers want their project to succeed. Educating them about ways that help
the project succeed, sounds like a worthwhile endeavor.

Vitaliy

2009\02\25@024340 by Vitaliy

flavicon
face
Jake Anderson wrote:
>> Jake, thanks. I'm becoming more and more conviced in the validity of the
>> YAGNI principle. Designing functionality that you *think* you're going to
>> use, is usually a waste of time.
>>
> Its easy, just think "what are we getting paid for"

We refer to this as "customer value". Somehow, it sounds less greedy. ;)


> Its a hot water heater, provided hot water comes out the pipe every time
> they turn the tap that's all the customer really wants.
> Make that bit work really well, then when your programmers want some
> "fun time" let them implement the LCD interface with some spare pins.

Indeed.


{Quote hidden}

Is this a gizmo that scans ISBNs, and checks how much the book is worth on
Amazon? :)


{Quote hidden}

You're right, with hardware it's a bit more difficult, but there are ways to
isolate the changes, and to shorten the turnaround time. We try to do two
things:

1. Build things in modules, as much as possible.
2. Order a small quantity of PCBs -- say, one or maybe two months' worth.
Sure, you'd pay less if you ordered enough boards to last you a year, but
then you can't make any changes to the boards, for an entire year. I see our
competitors doing this, we would open up their product, and see "(C) 2005"
printed on the board. We made the same mistake in 2003, and said, "never
again".

Regarding this last practice, we usually have a quick succession of
revisions after the initial launch, as we get feedback and add features that
customers want. Eventually, it slows down to the point where we order the
same revision twice or three times in a row. At this point, the product is
stable and it's safe to order a larger quantity to get a better discount.


{Quote hidden}

Time will tell, but I can say already that making changes to this code takes
less time.

Vitaliy

2009\02\25@062709 by Gerhard Fiedler

picon face
Vitaliy wrote:

> You keep covering your ears, and screaming "AGILE IS CRAP BECAUSE
> VIDEO IS BAD DOCUMENTATION!".

No. You scream. You are the only one who screams here. Feel free to
actually read the messages and find a single place where anybody besides
you has screamed.

> can _you_ read, Gerhard?

Should I answer this? It seems that only a moron can ask such a
question.

> "Communication", not "documentation"

As I wrote before, (good) documentation /is/ communication. This is
/obvious/. If your documentation doesn't communicate anything, it really
wasn't worth writing.

And while "Communication" is the title of the article, it seems to me
the article has contents also. And the curve I'm talking about, kind of
hidden below the title, in the contents of the article, is named
"Documentation". For a reason, I presume.

> To most people, it is obvious that a video conference is a more
> efficient way to communicate, than passing on a spec.

I don't know who those "most people" you cite are. Maybe they are
semi-illiterate? (I think "most people" in fact are semi or fully
illiterate.) It's definitely not obvious to me. Watching videos takes
too much time. I skipped most of the basic lectures in university,
because it is not an efficient means to get some stuff presented.
(Except for the few "spirited" lecturers, of course, but they were rare
in the basic courses.) Reading up on the stuff, I could do it in a
fraction of the time required. And I could explain it to the ones who
attended the lectures regularly.

I still wait for anyone to say "yes, I'd find it really helpful to have
datasheets in video form; it would help me get so much more efficient".
Datasheets may be an extreme example, but they are just documentation,
"a spec" as you seem to call it.

I also refer back to the billing system. Can you imagine a video
"documenting" this billing system? Instead of condensing all the
information into a readable and searchable document, they could have
simply shot videos from all the meetings they had with members of the
different departments where they discussed the thousands of individual
procedures and how they are related. That video would probably take a
few months to watch. Doesn't seem very efficient to me.


>>> It's funny when people diss on certain aspects of lean development,
>>> and try to convince me that it cannot work
>>
>> Who said that it cannot work? You really should avoid trying to defend
>> what hasn't been attacked.
>
> I refer you once again to Rolf's attempt at agile comedy. And to be
> fair, to some of your and Olin's posts as well.

You don't refer to squat. I never said that it cannot work, that's why
you can't come up with real examples. Repeating this doesn't change
this. All I said is that there are situations where some of the rules
don't hold, some of the approaches don't work well and alternatives work
better. And I stand by this, and nothing what you have brought up so far
has had anything to do with this. You seem to be arguing against people
who are saying that "it cannot work" (in general), but there are no such
people. All anybody ever said is that they have seen certain situations
where it didn't or couldn't work. Which you, if you had a bit of
humility inside yourself, could just accept. But I guess some do and
can, and some don't and can't.

Gerhard

2009\02\25@074409 by olin piclist

face picon face
Vitaliy wrote:
> We could have spent weeks agonizing over the details, but we chose not
> to

You are grossly overstating what a reasonable amount of up front planning
would have cost.

> -- because our time is limited, and engineering makes money only
> when it creates value for the customer.

Of course, but engineering the wrong thing doesn't make money at all.
Everything is a tradeoff, but some amount of effort is worth spending to
make sure you are designing the right thing in the right way.

> Most customers don't expect to
> see a Bluetooth module in an ECU Sim, they are interested in its
> primary functions (read the knobs, simulate OBD messages). But we saw
> that adding Bluetooth would essentially be free, so we dropped it in.

My point is that this should have been clear from the start and you could
therefore have made the decision at the start.

> Then we saw that multiplexing the plug-in modules would be a piece of
> cake, so we added two more PIM sockets, and the switch and an LED tower
> to go with them. UART over USB sounded like a no brainer, so it ended
> up on the main board as well.

These are all things that should have been apparent up front.  Perhaps I
misunderstand, but it sounds like you bumped into these realizations partway
thru the design.  If so you got lucky.  It could have worked out the other
way too.

> We kept making changes to the design, adding improvements here and
> there, long after the first release.

Design changes and multiple versions cost money.  From the description here
alone it's not obvious whether your approach was the most efficient at
arriving at the desired outcome.  I'm sure you think it is, but I'm also not
sure you are clearly imagining the alternative possibilities.

> I don't subscribe to the notion that experience can be measured in
> years. I've worked with enough different people to know that some
> programmers are still idiots at 60 (no matter what their resume or
> references say to the contrary). There are plenty of examples where
> great projects were led by young people. And, of course, vice versa.

Experience by definition takes time.  You are confusing experience with
ability.  Not all abilities require experience, and experience is no
guarantee of ability.  However, experience seems to be necessary for certain
abilities.  It is my obervation that being a good architect is one of those
things that requires experience.

>> Perhaps, but all too many don't understand development of any kind, and
>> don't want to.  That's why they hire out the project to someone that
>> can magically make it all happen for them.
>
> Customers want their project to succeed. Educating them about ways that
> help the project succeed, sounds like a worthwhile endeavor.

You clearly haven't tried to do projects for a lot of different customers.
Selling the result of your projects to customers is very different from
doing projects directly for customers.


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

2009\02\25@132908 by Vitaliy

flavicon
face
OK Gerhard, you win. Until things cool off, I will refrain from responding
to your posts.


----- Original Message -----
From: "Gerhard Fiedler" <spam_OUTlistsTakeThisOuTspamconnectionbrazil.com>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Sent: Wednesday, February 25, 2009 04:26
Subject: Re: [TECH] Upfront requirements and lean development


{Quote hidden}

> --


'[TECH] Upfront requirements and lean development'
2009\03\05@013716 by Vitaliy
flavicon
face
Olin Lathrop wrote:
> These are all things that should have been apparent up front.  Perhaps I
> misunderstand, but it sounds like you bumped into these realizations
> partway
> thru the design.  If so you got lucky.  It could have worked out the other
> way too.

How many times would we need to "get lucky", in order for you to concede
that the approach I described, works and (gasp) maybe is even superior to
the alternatives? Is the answer "never", because it doesn't follow your
vision of what "the right approach" is?


> You are confusing [...]

You keep using that word. I do not think it means what you think it means.


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