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.


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

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.


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

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.


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

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.


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

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.


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

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 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist