On Fri, 26 Nov 2004 01:07:37 +1030, Al wrote:

><snip>
>Normally these situations arise because the client has no idea what is 
>possible, and the 'designer' has not taken the time to adequately
study 
>the target industry, filter out what is desirable, and what isn't, then

>educate the client on what they really want.

This gets right to the heart of my earlier comments.  A designer really needs to
focus narrowly on assessing exactly what's required for a successful
result.
There is only so much resource and so much time to go around and it needs to be
conserved and focused well.  You do your job better when you don't squander
these, while still including what's important.

Jon

Jonathan Kirwan wrote:
> My advice is to be careful and not cavalier when
considering new features -- and
> especially ones that may add an unnecessary serial port, power
requirements,
> connectors, various software parts such as low and high level drivers,
parsers,
> flash programming features (which, on the MSP430 and on some other
controllers,
> limits the voltage range and adds peak current requirements to the existing
> power system), etc., all for the idea of "Hey, let's add the
ability to download
> customer messages!"

I know this is only a hypothetical problem and I probably shouldn't get 
involved, but...

The way I would do it is to put a lookup table of strings (perhaps 
packed/compressed in some way to save space) at a fixed location in 
flash and write a simple script which reads a 'language definition' 
file, builds the table, checks it isn't too big to fit in the device, 
and writes it into the program hex file in place of the existing data at 
the language table address. All the client has to do to create a 
firmware image in a new language is to translate the strings in the 
language file and feed it to the script. It's even possible for the 
strings to contain some kind of formatting sequences, but that does 
significantly increase the likelihood of the client managing to to break it.

-- 
------------ Alex Holden - http://www.linuxhacker.org ------------
If it doesn't work, you're not hitting it with a big enough hammer

Hi All,

It seems we all have our share of projects gone wrong.

The worst projects for me are always the ones where the client is the expert
but they don't actually know.  You are just following their directions and
the reason the code doesn't work is that you have screwed up.  As the
outsider, all the insiders want it to be you fault.

I have also had to pick up projects being done part time by a university
student where they had actually made a pretty good fist of it given their
level of training and expertise, but it wasn't an easy job to start with
and
the client has gotten used to the value equation that a university student
represents to his budget.  Apparently I'm just meant to tweak it and all
will be well.  Sometimes they aren't salvagable at all.

And sometimes businesses work out that the product won't make money unless
the development costs less than X.  This is at least a good thing that they
do work out the likely return on investment profile.  But whe you can't do
it for X they think you are ripping them off.  The logic seesm to be that if
it has to cost X or else the project will lose money, then X is what it is
worth and any figure higher is robbery.  It doesn't seem to also occur to
them that maybe their assessment and yours are both correct and there isn't
a business case for this product.

I try and provide a fixed cost service but I only do this on the basis of
'fixed price = fixed deliverables'.  If they haven't done a
requirements
analysis (seems to be a dying art) or I can't get a really good
explanantion
then I can't really offer fixed price.

I did one project where the engineering manager had sacked the hardware
desinger, resigned not long afterward and was leaving the country for a year
or so that week.  They had a remaining team member who was a PIC assembler
programmer and another who was a technician.  I was starting next week for
an 8 week stint to clean up the PCB layout and tweak the software so they
could go into production.  The product had 2 major features and the one
demonstrated seemed to work OK and the problems were described as being
associated with the PCB layout causing digital noise to interfere with the
analog electronics.  The software was DSP code in assembler.  9 months later
we had a completely new design (now with International Patents) and there
were only 3 main components still the same: the case, the custom LCD and a
wound ferrite antenna.  Email contact between the ex-Engineering manager and
the client's General Manager still insisted the problem was my competence
even to the end though the results of the first weeks trials of the first
design spoke for themselves.  They didn't demonstrate feature #2 because it
hardly worked at all.  And the battery power consumption was 30 times the
number required to give then their specified battery life.

And I have done a lot of projects where the client was reasonable,
understood development processes and risk management (I also really believe
risks are best managed), and prefered an honest assessment.  I keep getting
work from these clients year in and year out because they know how to be
successful and we have built a good working relationship.  May there be many
more of these.

Ray

On Thu, Nov 25, 2004 at 03:06:50PM -0000, Paul Curtis wrote:

> > The BUDGETS BLOWN PROJECT. This usually
occurs where one of 
> > the below scenarios has unfolded to its obvious conclusion. A 
> > mess. The potential client hired company A because they 
> > wanted a 'reputable firm' or because so and so who works in 
> > the typing pool has a brother who knows the uncle of the 
> > company owners wife. Anyway, they've been charged big bucks, 
> > the project is way over time, and way over budget. 
> 
> This is the "THE GRANDIOSE TAX-SAVING GOVERNMENT PROJECT"
scenario, also
> known as the "EDS BOTTOM LINE SUPPORT PROJECT" as it typically
fails,

Do not forget the Toll-Collect project in Germany. (truck maut)
This project is done by the biggest german companies and the first
start of it failed due to not working electronics. Regardless the fact
that there are working maut systems in Europe they must develop
a new system that can do almost anything (not only collect maut).
 Actually they should pay the lost maut; but in practice they pay much much
less. Second try is beginning next year, we will see...(I doubt)
Interestingly the word 'toll' means mad in german.

http://www.silent-penguin.com/archives/001308.html

I wondered in the past why so many people are studying industrial management
or business administration (and so few engineering), and I wondered what
they will do after the study. Today I know it - bullshit. 

M.

----- Original Message ----- 
From: "Raymond Keefe" <ray@ray@...>
To: <msp430@msp4...>
Sent: Thursday, November 25, 2004 10:19 PM
Subject: [msp430] Projects gone wrong - was C Compilers


>
> Hi All,
>
> It seems we all have our share of projects gone wrong.

When I joined my previous employer, they had paid a large amount of money to 
a company to design DSP-based hardware to execute code that had been 
prototyped on a PC using C, and port the software to it, coding time 
critical portions of the software in assembler. Said company eventually more 
or less gave up on the job after they got the hardware and the software more 
or less working, albeit very slowly, and admitted that they couldn't do the

conversion to assembler. I redesigned the hardware, making it a lot simpler 
and cheaper, and wrote the assembler code without too many problems. I 
couldn't understand the C code that had been written, and there was no 
documentation to speak of, so I got the software engineer who had written 
the original C code for the PC to structure his code properly so that I 
could convert it to run on the DSP (he still complains about me doing that). 
I then hit all sorts of problems with the development  tools for the DSP, 
and was given an advance copy of a new version, which was full of bugs, and 
eventually got the job done. The company we originally commissioned to do 
the job ended up being taken over by ARM.

Leon

Similar, I guess, but mine have been real projects...

The Home Brew Mining Co.

BIG mining company geology grad meets hobbyist HAM radio enthusiast. 
Over drinks get big idea for tracking mining fleet. Hobbyist has 0 micro 
experience. Cobbles together a 6809, packet radio and support circuits. 
All on Veroboard, all DIP, all socketed. Takes 3 years  durign which 
time inexperienced mining company pays guy on average $5k/wk + buys all 
parts at retail prices, + furnishes the best electronics lab I've ever 
seen outside of a $m firm (4 RF spectrum analysers that I know of 6 PC's 
  ?, 2 analog scopes , 3 digital scopes, sig gens, psus, you name it 
this guy had 2 of it. Add to this he was selling them each board, which 
they'd paid for for $12k.

All power to his elbow if he can get this much. problem is nothing 
worked. The record for functionality was4 hours in a static truck, 40 
minutes in a moving one. Mining co hires Tech manager. Suspicious tech 
manager phones me. 6 months later original prototype is operational, it 
no longer shakes the parts out of sockets, no longer has to force a 
system reboot every 10 minutes because the code has eaten itself, no 
longer has to rebbot the trucks own processor, because its been addled 
by the screwed up comms etc. System can hanlde up to 4 vehicles before 
packets start getting oirretrievably lost. 12 months after that a 256 
vehicle system is deployed, 99.99% message delivery guaranteed. No 
hardware or software issues occur during next 5 years.

This is the dumb client/useless engineer scenario.

GOVERNMENT funded project, swallowed $m's so far over 8 years. Project 
is liquid propane injection. Still no relaibly working vehicle. Funding 
about to be withdrawn. Project has had several in house and out? house 
engineers, all have been through the 'needs redesigning the last guy was 
crap' scenario, or the "needs reprogramming the last guy was
useless' 
scenario. Accidently bump into car outside my little office where I have 
a two man engine management company. Car is coughing farting and blowing 
black smoke. Talk to driver, get gist of story, 'consultant' engineer 
sounds like YAW (yet another wa***r). Drop ROM, disassemble, hack chip, 
car stops blowing smoke, has many many problems , but survives 500 mile 
drive back to Adelaide from Melbourne. 1 week later receive call, agree 
to see if I can get thing going. Receive old version of source code, and 
a car owned by the company on 4th December, just for review. Any sane 
person would have walked away then. When I called the 'consultant, and 
queried why he had 300 line ISR's, didn't use a single bit instruction

in the entire program (HC11E series), let alone using labels like, xx, 
xxx, xxxx, sexyme, Irock, irock2. His reply was, good engineers don't 
use bit instructions, they're the sign of a bad programmer. What 
difference does it make how long an ISR is.

Drove to Adelaide 14 january. Had vehicle running reliably by 6th 
February. hacked 60% of the hardware off, and complete code re-write. 
some 20+ cars are still running around South Australia with the system 
fitted. Told the Federal backers that the actual gas hardware, and the 
PCB both needed re-designing, they couldn't be built for a commercial 
price. Despite showing them a new design that achieved 1000km/tank vs 
570 highway, and doubled the city cycle range of a taxi they scrapped 
the project. $48m invested, then scrap it just as it gets solved?

This is the EVEN THOUGH YOU BAILED US OUT WE DON'T TRUST YOU scenario. I 
lost $72k on that project. It ticks me off the car emissions were around 
10% of that on ULP, 18% more power and torque, just by changing the 
fuelling system, and it used a fossil fuel that currently pollutes our 
atmosphere because most of it can't be sold, and it is flared off.

Oh well.

Al



Paul Curtis wrote:
> Al, 
> 
> 
>>Hi Kent, interesting! Very jaded outlook for one so young 
>>;@}, and you missed what, to me anyway, has been my greatest 
>>source of income.
>>
>>The BUDGETS BLOWN PROJECT. This usually occurs where one of 
>>the below scenarios has unfolded to its obvious conclusion. A 
>>mess. The potential client hired company A because they 
>>wanted a 'reputable firm' or because so and so who works in 
>>the typing pool has a brother who knows the uncle of the 
>>company owners wife. Anyway, they've been charged big bucks, 
>>the project is way over time, and way over budget. 
> 
> 
> This is the "THE GRANDIOSE TAX-SAVING GOVERNMENT PROJECT"
scenario, also
> known as the "EDS BOTTOM LINE SUPPORT PROJECT" as it typically
fails,
> costs the taxpayer a shedload, EDS or Siemens don't need to deliver
> anything working, and they get of scot free, get paid, and are anxious
> for the gravytrain to continue!  We've had our fair share of them:
> 
> Child Support Agency (EDS):
>
http://news.independent.co.uk/low_res/story.jsp?storyX4793&host=3&dir=
> 62
> 
> Passports & "anybody can have a UK passport if you can write your
name
> and promise you're not a terrorist" fiasco (Siemens):
> http://www.findarticles.com/p/articles/mi_m0CGN/is_1999_July_6/ai_550716
> 79
> 
> NATS New En-route Centre (IBM/Loral):
> http://www.computerweekly.com/Article109436.htm
> 
> It even happens that we don't even know what it costs to build a place
> where Members of the Scottish Parliament can all gather and
> chat--incredible!
> http://www.gallowaygazette.com/servlet/ContentServer?pagename=Newspaper/
> Article&pid45579536650&cid67414664684
> 
> Nose to the grindstone everyone--we need to support EDS and Siemens with
> our taxes!
> 
> --
> Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
> CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors  
> 
> 
> 
> .
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 

Hi Al,

for the liquid propane injection project, who owns the IP?  Should be
progressable on commercial grounds if you can secure it?

Just an idea.

Ray

Yeah, yeah, I know I'm ages behind the thread...

Richard said:

>> We are pretty much being "forced"
into it. Remember we have
multiple product lines. On the MSP430, IAR has been giving out
freebies. On the Motorola/Freescale, Metrowerks give out compilers
like candies. <<

I think the problem for Motorola has been that for the smaller HC08s
like the Nitron, they had to offer a cheaper C compiler to compete
with the likes of PICs. The easy way to do that was to offer code
limited versions of Codewarrior. I think it's easy to see why Mot did
this: customers often moan about having to pay for tools; they often
think that they should be offered free tools by the semiconductor
manufacturer. I'd rather pay a sensible amount of money (not IAR or
Metrowerks "full" prices) and get some decent, responsive support like
you get from Codevision, Rowley, Quadravox etc. (I'm sure you offer
good VFM and support, Richard, it's just I've never tried any of your
stuff! :-)


>> On the AVR, there's the low cost
competitor from Romanian. <<

I assume you mean Pavel at Codevision? He does an unbelievable job I
think. It's a great compiler at a truly fantastic price. He does have
the luxury of not having to worry about the debugger though! 
 
I believe he's developing a compiler for MSP430. I assume this will
have a debugger with it.

Cheers,

Rob

Robert,

> >> On the AVR, there's the low cost
competitor from Romanian. <<
> 
> I assume you mean Pavel at Codevision? He does an unbelievable job I
> think. It's a great compiler at a truly fantastic price. He does have
> the luxury of not having to worry about the debugger though! 

There are, of course, compromises with this system, not least of which
is no separate compilation, no full support for the C language, and no
debugger.  Other than that, it seems OK, but the code it generates is,
err, rather bloated.

> I believe he's developing a compiler for
MSP430. I assume this will
> have a debugger with it.

Brave man.  There are too many C compilers for the MSP430 now.  I don't
think the MSP430 tool market can stand much more in the way of
additional compiler toolsets.

-- Paul.

Hi Robert,

> I'm also not that bothered about there being
no debugger because the Atmel 
> Studio debugger is just about the best debugger I've ever used;
it's free and 
> Codevision works seamlessly with it for me. :-) 

I too felt spoilt with AVR Studio, very nice debugging, and then came
CrossWorks :-)
I'm actually as we speak/type doing an RF Modem for a client with AVR
Studio
on ATMmega32 and JTAGIceMKII - using ICC-AVR.
What a stuntled clock system, bah - gimme MSP430 anyday :-)
(The fuse setting is a pain, can't "boot" of an internal Osc when
injecting Ext clock)

-- Kris