Best Practices to Manage Complexity in Hardward/Software Design?

Same as me, then. That's why I am so obstinate about "design", about getting it right. If not "first time", so "some time". "Early" would be preferable.

Sure. The problem is, as you indicate, when one does not discriminate between an initial prototype and the finished product.

Must of the bugs I've found, were typos or other blunders that made me look plain stupid. There were one or two, though, I learned a lot from. Here is one that took me a month to find. I only understood there was a problem after I ported the code from one system to another.

/** C code *************************************************/

float a; float *p; int i;

/* initialize p as an array containing N > i floats */

a =3D *p[i];

/***********************************************************/

Now we are talking. "Making it part of the planning process."

Or it might screw the whole thing up, what subsequent extensions are concerned.

Rune

=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF

Reply to
Rune Allnor
Loading thread data ...

It seems to me that much of this discussion is tempered by the size of the organization that each participant is involved in.

For virtually all my career, I have worked (and had ownership in) small companies. I think this case, the marketing & engineering aspects of the projects tend to be more naturally coupled together and management is not likely to be pointy haired.

In most of my larger projects (which for me might involve 4-5 people), we usually had a fairly good vision of what we wanted to accomplish when we started, but at the same time, we never over specified a project from the start.

Nevertheless, we rarely built lots of small incremental prototypes, it takes too long. We used kind of a successive approximation method that was drove to the production version as soon as possible. Sure, we might have prototyped small segments as needed. In most projects, the collective talent already knows how to do 80 - 90% of the project before it even starts (or knows where the answers lie). Dotting every i and crossing every t, is very slow. You also tend to create a number of very good useless pieces that you discard anyway. If the project takes too long, the solution may no longer be relevant.

I think the key to the successful projects, that I worked on was that everyone understood the basic vision, and there was always a architect on the project that understood the broader issues. You can always find a better way of solving a problem the next time. Sometimes, its because you learned something from the previous project, sometimes its new components (like a new DSP chip), sometimes its economics, etc. One of the challenges for the project leader (who in our case was usually the architect), was to access when to change course in the middle of a project and when to stay the course (and sometimes shoot the engineers).

I have killed projects in the middle and almost completely started over. This is painful, but usually, the next attempt is a lot better.

Probably, the most successful project I was involved in started with a well defined goal, that had 2.5 months to bring from idea to production (including deliverable products). The timing was forced by a trade show.

We designed everything as a production solution (extruded housings, injection molded bezels, custom circuit boards, firmware, etc). We didn't even start the firmware until the last week before the tradeshow. This was actually part of the plan since timing was everything. The team consisted of 5 people.

Suffice to say, we were the most successful exhibitor at the tradeshow. We had people standing three deep into the exhibit floor most of the show. After about a year, we had captured about 80% of our market (we had two competitors when we launched our product at the tradeshow).

If we had followed the build a little, test, build a little more, we would not have succeeded since time to market would have let the opportunity slip away.

--
Al Clark
Danville Signal Processing, Inc.
 Click to see the full signature
Reply to
Al Clark

Hello everyone, I am floored by the number of responses to my original post. I want to thank everyone for taking the time to express their thoughts, experiences and opinions. I also want to pass on a document I found on the internet,

formatting link

If you have some free time check it out.

Again, I want to thank everyone for sharing their opinions.

joe

snipped-for-privacy@hotmail.com wrote:

Reply to
jjlindula

I'll see you and Peter in the marketplace.

--
%  Randy Yates                  % "Ticket to the moon, flight leaves here today 
%% Fuquay-Varina, NC            %  from Satellite 2"
 Click to see the full signature
Reply to
Randy Yates

Randy Yates wrote in news: snipped-for-privacy@ieee.org:

This is my view as well.

I love that last line.

--
Al Clark
Danville Signal Processing, Inc.
 Click to see the full signature
Reply to
Al Clark

Me too Al. An awful lot has to do with product cycle time.

I worked at a place where the cycle time was quite short. There was lots of re-use of "infrastructure parts". So, the idea of making many changes after the initial design was pretty remote. There wasn't time if we were going to get to market. The products weren't obsolete with a cycle time that could be under 1 year. We also relied on field programmable FPGA designs. So, changes weren't out of the question but were "soft" in that sense and didn't necessarily count in the "few changes" sense of things.

Fred

Reply to
Fred Marshall

Well, I did see -- from a safe distance, thankfully -- a software project in progress, that did "produce results" extremely quickly. Somebody was making some sort of data processing tool. The department (perhaps even the people) involved in this particular project, had at a previous time been involved in developing a production analysis tool of similar nature.

What had happened in the mean time, was that both matlab and IDL had provided GUI development tools as part of the programming system.

So these guys were capable of producing a GUI where the data was visualized, manipulated and handled, along with some simple IO etc, in a matter of hours. Previously, they had used weeks or months for design, analysis etc, before starting coding, let alone have a demo ready to show.

People were flabbergasted by the "results". The nice, fancy images on the screen. "This proves that those guys from the other department, who ran the previous project and insisted on all that bueracracy, had no idea whatsoever what they wre doing."

Sure, the demo was impressive enough. But could it handle production- type data sets, that could be tens of gigabytes? I don't know. Could it be maintained in a decent way? I don't know. Could it be extended with further functions? I don't know. Could the GUI be changed easily, if the intended users had remarks on the operation? I don't know. Could it be modified to accomodate slightly different analysis tasks? I don't know.

In this case, the demo was percieved as "a product", right here and then. No one who asked for time or resources to "get it right" would get anything; there was no need for it. The program was already there, running, "working".

And the serious long-term effect (which I got to know first-hand) was that there was no need to allocate neither time nor other resources in future programming projects: These guys had produced "a product" in a matter of hours, using the site lisence of either matlab or IDL. Everybody else was expected to do the same.

All my efforts to get the department to make decisions on data formats, analysis tools, establish procedures for QC, data validation, storage formats, reporting standards etc (I thought that getting/making

a software tool for these kinds of jobs might force people to make decisions of this nature) were met with "It generates too much bueracracy, people do what they want anyway, and it takes no time to make a system for the scarcely few instances it might be useful."

Sure, that's the only way to train people. Still, I have yet to meet somebody who don't have hands-on experience with coding and implementations, who do understand the difference between "demo GUI" and "product", to paraphrase the example above.

I don't think it is the full explanation. Lack of hands-on experience with system analysis and programming, is more likely.

Rune

Reply to
Rune Allnor

and

Making the change can be as easy as yawning, and still be a nightmare.

We had just bought some new data acquisition system, and was preparing to take it to sea for the first time. The system both controlled the ADC and stored the data to files, and it was up to us to sort the files out, rename and archive them according to the project, survey, run, etc. The system was, as far as I know, one of the first of this make and model to be sold. I would expect the supplier to be interested in getting customer feedback, and make those small changes the users would like, to make it easier to

operate.

So the engineer in my department who was responsible for the kit, came up with the very sensible idea that the raw data files as generated by the

acquisition system, should be named according to the time they were started. The files would get a name as a numerical value according to

filename = YearMonthDayHourMin

which would yield a unique file name for each file. All we had to do, then, was to make a script that compared the file name to the survey log we anyway would have to write elsewhere. Whoever wanted to use the data files after the survey, would have to relate to the survey log anyway.

The supplier of the system had no objections to doing the change, but our engineer had not been very precise in writing the requirements. She had indicated the change much like I did above, but when we tested the code (at sea, on our way out to the first survey this piece of kit would be used...) we got a result like

Year: 2006 Month: 7 Day: 7 Hour: 14 Min: 42

filename = 2006771442.data

The problem? No leading zeros to identify single-digit months, days, hours or minutes, making the file name ambiguous with respect to when it was generated. For instance, was the file

2006112130.data

generated at 2006 January 12th 0130 hours, 2006 January 1st 2130 hours, or 2006 November 2nd, 0130 hours? There is no way of telling, unless the time stamps in the file systems are preserved, which they are not guaranteed to be.

The required spec ought to have been

filename = yyyymmddhhMM

As far as I am concerned, getting it right once the error was discovered ought not to take more than 2 minutes. For some reason, the second request did throw a serious spanner in the works, what the relationship to the supplier was concerned. I have no idea why, although it might be that a controversy over some adjustable gain settings had something to do with it. I frequently changed the gain settings of the ADC during the survey, to make up for the somewhat limited dynamics of the fixed-point

ADC. For some reason, the gain settings were never stored in the data files, so I could not use the data files for my purposes when we got back to the lab.

I don't know if the time-coded file names ever were generated correctly.

Rune

Reply to
Rune Allnor

Is that a threat or a promise? Or both?

:-)

Ciao,

Peter K.

Reply to
Peter K.

[SNIP]

If it could be truly demonstrated that, for this particular company, that approach worked... why not?

It certainly sounds like a pretty retrograde step they way you describe it, but if the company could survive by doing things that way (even if it goes against all the good ISO-9001:2000 / CMMI stuff), then it might be a valid way to go.

I certainly have come across people who insist on taking an hour to do something... and every time they do it it takes them an hour. Whereas the I try to figure out how to automate it so that, the first time, it might take me an hour and a half... but the second time takes my 20 minutes, and subsequent times 5 minutes. The people who don't do the hard hour every time don't appear to understand the tools at their disposal, or can't systematize their thinking about the problem enough to use them effectively.

Maybe. I've been fortunate enough to be able to convince my higher-ups to go along to some of the technology training courses so they understand (at a high level) what we're trying to do and how we're trying to do it.

And them not taking the time to get that experience is, IMHO, indicative of the attention span of a gnat.

Ciao,

Peter K.

Reply to
Peter K.

It's about proepr use of manpower. Manually, the post-experiment data organization work takes 3-6 months, prior to any analysis. Most of it is drudgery. Automize that to take, say, 1 - 2 weeks, and the crew is free to do interesting or even useful stuff. And you can cut project time and cost with ridiculous amounts.

Some see the ISO 900x stuff as added bueracracy. It may well be, but it might also be a very powerful tool to streamline the production, if used wisely.

In all the marine surveys I know of, either I have taken part myself, used the data or seen my colleagues be involved in, there have been ridiculous amounts of drudgery involved. I have seen -- not been involved in, personally, though -- surveys where it took 4-6 weeks from the guys came back to the lab to they could start working with the data. In the mean time they did QC, archiving, adding geometry, re-formatting,... you name it.

People get unbelievably bored by doing this kind of work in the first place. Even more so, by doing it for so long time. When people are bored, they get sloppy. They make mistakes. There is no need to blame anyone for that, it's merely human nature.

But we need the data, and we don't want all those inevitable mistakes, due to boredom, to invalidate the data. Experiments are expensive. Some times even useful.

So the way to do this, is to formalize and automize as much of the process as possible. If you make a software system for format control, and make a sensible user interface, the crew can start the re-formatting job while in transit back from the survey site. After weeks at sea, they will most likely be in "zombie mode", but the are still capable of clikcking boxes in a GUI and filling in descriptions in a dialogue box, as required. A data validation system that take scarce pieces of information and stores it in reports, will save incredible amounts of time, not to mention if some reorganization of data files can be done as well.

I wouldn't let anyone who have been to sea for any amount of time, near such a task for at least a month after the return, if it must be done manually. After a month, people will not be motivated to get back to work on the data, and we are back to the circle of boredom - demotivation - sloppyness - errors.

So jumping on the ISO 900x frenzie provides managment with a nice diploma to hang on the wall, and the crew with an excuse to think their activities through. Not to mention that the ISO 900x certifcate is a compulsary requirement prior to getting certain types of projects.

Well, it's a waste of my time if I have to wait for hours or weeks for them to provide me with the data I want and need.

Rune

Reply to
Rune Allnor

Definitely!

Show management the $ different between 3-6 months and 1-2 weeks, and you'll have your case sown up (they'll be begging you to do it!).

I was involved in a small company that needed ISO9001-2000 accreditation to be considered as a supplier for a major company. The company was a start-up and we had complete freedom (within the constraints of ISO9001) to write our own procedures.

What we did was to figure out what we were doing (and why we were doing it), look at some "best practices" to see if we should be doing anything else, and wrote that down as our quality manual.

Because we had the luxury of defining it ourselves, and because we involved as many people as possible in the discussion about it, we had really good buy-in and understanding of why the process was necessary.

Heck, we even passed ISO accredition first time with only the minimum allowable set of data (I think it was 3 months).

My biggest reason for getting the system in place was for clarity of communicaiton: among team members, between teams, between team leaders and upper management, between our company and suppliers, between our company and customers.

Ciao,

Peter K.

Reply to
Peter K.

Brilliant.

Yeah, those are the exact reasons why I am positive to ISO 900x.

Rune

Reply to
Rune Allnor

It's a fact.

--
%  Randy Yates                  % "Maybe one day I'll feel her cold embrace,
%% Fuquay-Varina, NC            %                    and kiss her interface, 
 Click to see the full signature
Reply to
Randy Yates

I doubt it! Our marketplaces (or those of the companies we work for) are quite different...

Ciao,

Peter K.

Reply to
Peter K.

If you still think I work for Sony Ericsson, you'd be wrong.

--
%  Randy Yates                  % "Though you ride on the wheels of tomorrow,
%% Fuquay-Varina, NC            %  you still wander the fields of your
 Click to see the full signature
Reply to
Randy Yates

...

Why implement from the bottom up?

-scott frye

Reply to
scottf3095

The document has some good infomation, many of my mature customers tell me exactly what documentation I need to produce so I really have no choice in the matter!

One comment I thought strange in the document was

"I have worked for Parker Hannifin, an aerospace company where mistakes result in people being killed. I have worked for Mattel, where the only factors that matter are how soon you can get the toy into mass production and how far down you can get the per-toy costs. "

I am sure Mattel has killed more people then any aerospace company due to its engineering mistakes. (small parts choking kids, electrical toys starting fires, sharp parts cutting, wires choking, lead poisoning etc etc).

Reply to
steve

Ah. That could mean a change, then! So what is it? Jet engines? Elevators? Air conditioners? Helicopters? Electronic security? Space suits? Fuel cells?

You haven't updated this! :0)

Ciao,

Peter K.

Reply to
Peter K.

Because part of the implementation usually includes "unit" testing, or testing of the pieces, and you must begin such testing with the smallest pieces possible. Then, when the "foundation" is implemented, you can begin assembling the foundational pieces into small subsystems, test those, then piece those together, test those, etc., until you have the entire system.

--
%  Randy Yates                  % "She's sweet on Wagner-I think she'd die for
Beethoven.
 Click to see the full signature
Reply to
Randy Yates

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.