??? 10/18/11 15:08 Read: times |
#184261 - After 30+ years as a consultant ... Responding to: ???'s previous message |
Jez Smith said:
I was thinking about this he other day, working in consultancy you get to see a lot of different projects and you have to be able to see the problem from all kinds of angles, commercial, ease of manufacture, test-ability, cost and so on. I was thinking really this is an approach that most people would call real engineering and it contrasts with the current rise of the idea that you throw software at a problem until it breaks, I have seen people write c++ classes to handle the ADC on an 8 bit processor and you think erm....yeah.
I think this is why I don't like geeks who see software as a hammer and every problem as a nail. It's true, you'll see a lot of different types of projects, and apply a much wider skill set than if you're "working for the man". Unfortunately, you'll see a lot of partially done work that you're now required to make "work", where "work" is often poorly defined. What's more, engineering staff will hate you because you're brought in to find and repair their screw-ups. Unfortunately, you're never at liberty to point out where they've gone wrong, i.e. when management has interfered with the normal process of engineering, either by providing inadequate resources or by micromanaging the effort. I've grown tired of being brought in to "fix" problems resulting from poorly made premature decisions, foolish component selection, failure to specify the initial requirements, inadequate analysis, and choices of practices and components that are "kewl" rather than what makes sense. Unfortunately, that's what consultants see time and again. We're brought in to play catch-up, seldom to do the sensible "start-over" that's warranted by all those things already enumerated ... <sigh> ... and mostly because we're willing to do what the on-staff personnel are unwilling to do, namely the 30-hour days 8 days a week that will bring things back to on-schedule status. From where I sit, two things are totally essential. 1. Fully understand the requirements, write them down, and get the "boss" to sign 'em. Now map the design into that requirement set and include nothing that's not warranted by the requirements, and ensure that all the requirements are addressed. 2. Design a test procedure set and the required test environment, including hardware, that verifies that each of the requirements are, in fact, addressed and system behaviors as specified in the requirements set are verified. Be sure that your contract specifies each of those tests as proof of completion and acceptance. If you don't do (1), above, then you're "p*ssing into the wind", and if you don't do (2), it's unlikely you'll have an easy time getting compensated, and even when you do, you'll wind up with a bad taste in your mouth. I've tried, over the years, to avoid involving myself in the business decisions, i.e. the things affecting cost, time to market, exterior packaging, unless specifically asked to do so. That will save you lots of whiskey, antacids, aspirin, and prune-juice. I long ago stopped worrying about whether the client's business would survive. That's a management problem. I do like it when clients who pay their bills on time stay around and call me for the next job, but if they are the sort that worries about appearance over substance, and doesn't plan a route to the end of the job, well, I don't mind seeing them go under. I'm certainly not going to waste any of my own time or effort on their management errors. RE |
Topic | Author | Date |
Thinking about designs | 01/01/70 00:00 | |
Real engineering | 01/01/70 00:00 | |
After 30+ years as a consultant ... | 01/01/70 00:00 | |
yes, they do | 01/01/70 00:00 | |
On and off for 20 years... | 01/01/70 00:00 | |
I've had similar experience, but not in firmware | 01/01/70 00:00 | |
how true | 01/01/70 00:00 | |
That must be ... | 01/01/70 00:00 |