FPGA Central

In comp.arch.fpga,comp.software-eng and comp.dsp, On 21 Jul 2005
11:21:05 -0700, "jjlindula@hotmail.com" <jjlindula@hotmail.com> wrote:

>Hello, I'm interested in how individuals or design groups manage
>complexity in their design projects. What things do you do or things
>the group does that can take complex tasks and break them into simpler
>or more manageable tasks? It may sound like a weird question, but there
>must be some guidelines, best practices, or habits used to achieve
>success in designing/developing a complex project. I'm sure there must
>be some individuals out there that are constantly taking complex tasks
>and just about every time have success with it. Short of speaking, I
>want to know what's the secret to their success. All comments are
>welcomed, even the most obvious suggestions.
>
>As an engineer, I'm constantly trying to improve my design processes.

The big company I worked for at the time sent me to a week-long
"Software Engineering Training Program" while in the middle of a
longish project. I recall it being a mostly "positive learning
experience" but the only thing I now (10 years later) remember from it
was "Do a post-mortem on the project." When you get done with a
project (whether it's shipping or it was trashed), you (meaning the
whole team) look it over (perhaps not so much the design itself but
rather how you did it), see what you did right and what went wrong,
what you could have done better, etc. The point of this is that you
might have better insight at the start of the next project, rather
than at the end of it.
Of course, at the end of the project I was working on, we did NOT
do a post-mortem.

>Thanks everyone,
>joe

-----
http://www.mindspring.com/~benbradley

Ben Bradley wrote:
>
> The big company I worked for at the time sent me to a week-long
> "Software Engineering Training Program" while in the middle of a
> longish project. I recall it being a mostly "positive learning
> experience" but the only thing I now (10 years later) remember from it
> was "Do a post-mortem on the project." When you get done with a
> project (whether it's shipping or it was trashed), you (meaning the
> whole team) look it over (perhaps not so much the design itself but
> rather how you did it), see what you did right and what went wrong,
> what you could have done better, etc. The point of this is that you
> might have better insight at the start of the next project, rather
> than at the end of it.
> Of course, at the end of the project I was working on, we did NOT
> do a post-mortem.

Very common.

I was involved in one of those hellish development projects that
resembles a slow moving train wreck.

The project was supposed to take 9 months but ended up taking over
2.5 years. Near the end, I offered to write a paper on what went
wrong and how to avoid similar problems in future projects. I made
it clear that I was not looking to blame anyone but I wanted the
company and the development team to learn from the mistakes made.

My offer was ignored and I left the company 4 months later to
go to a job with about 5% less pay.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Linux is produced to be used, whereas the others are produced
to be sold" -- Bobby D. Bryant

Erik de Castro Lopo wrote:
> I was involved in one of those hellish development projects that
> resembles a slow moving train wreck.

Only one? Your career must have been truly blessed. :-)

Steve

Steve Underwood wrote:
>
> Erik de Castro Lopo wrote:
> > I was involved in one of those hellish development projects that
> > resembles a slow moving train wreck.
>
> Only one? Your career must have been truly blessed. :-)

Well after that disaster I spent three and a half years doing technical
support in the most senior level of support at SUN Microsystem.

I'm now back doing development work and find that things haven't
changed much :-).

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"I don't think any MS Exec will ever die of old age. Satan
doesn't need the competition."
-- Digital Wokan on LinuxToday.com

Erik de Castro Lopo wrote:
(snip)

> I was involved in one of those hellish development projects that
> resembles a slow moving train wreck.

> The project was supposed to take 9 months but ended up taking over
> 2.5 years. Near the end, I offered to write a paper on what went
> wrong and how to avoid similar problems in future projects. I made
> it clear that I was not looking to blame anyone but I wanted the
> company and the development team to learn from the mistakes made.

Read "Mythical man-month", which pretty much has the same description,
though on a different scale.

It is written by the head of the OS/360 project. The examples relate
to software projects, but it should be more generally applicable.

-- glen