[prog] State of software engineering profession
jching at flex.com
Wed Apr 16 01:21:41 EST 2003
On Wed, 16 Apr 2003, Mary wrote:
>On Mon, Apr 14, 2003, Jimen Ching wrote:
>> 1. Keep the same group of people throughout the project's cycle.
>> When people are moved in and out of a project, the goal and design
>> loses focus. This is never a good thing for a project.
>> 4. Never schedule the entire project. It will never work out anyway.
>> Instead, identify major milestones, and schedule only to the next
>> milestone. Of course, you should know the alotted time for the
>> project. And, this may be obvious but, have a prioritized plan before
>> coming up with a schedule. How else can you develop a schedule? ;-)
>> 4a. Always give youself two weeks of slack when dealing with
>> hardware. Note, the slack should not include delivery of hardware.
>> In other words, if you've scheduled a month for a driver for some
>> hardware, starting from the PO to a working driver, add two weeks to
>> 4b. Try to identify the highest risk hardware as soon as possible and
>> set it in motion. High risk hardware are defined as hardware that is
>> new (to the market), or that you haven't worked with before.
>I've quoted the above because I want to ask you a question about these.
>The question is:
> Assuming you are not running your own company, how do you go about
> convincing management of these?
For (1), describe the benefits that will result from following this
practice. AND, describe the potential problems that may occur if it's not
followed. Be inventive when trying to come up with reasons to keep your
group together. I.e. say things like Mike is the only one who knows how
to do so and so. If we lose him, it would require a month to retrain
someone else. Well, you get the idea. Then, if the manager decides to
ignore your complaints, then you have at least tried to do the right
(4) and (4a) is usually done by a project lead. Who is depended upon to
give an accurate schedule. I'm only suggesting that slack be added for
unforseen events. Often, project leads wants to assume everything will go
as planned. But this almost never happens when unknown hardware is
(4b) will require the entire team to perform. The management would
probably want the team to identify the hardware that will be used, as
things like funding may affect the decision. This rule simply points out
that high risk hardware should be treated special, because of their
Note, when I say hardware, I don't just mean metal that goes into the
final product. Hardware also includes test equipment for these metal
parts. If the intent is to get a loaner, you want to order at the right
time so someone is free to learn how to use it and actually use it. You
don't want to order it too earlier or too late, which will increase the
loan period, which also increases the cost.
I'm sure the manager will appreciate your efforts to reduce costs. ;)
>Another question is:
> Do you have any method of addressing the most frequently cited
> problems in my posts and Rboert's? These problems were:
> - completely unrealistic hard schedules set by management (and
> worse, often by contracts with the customer);
Well, tell them this.
The schedule is not likely to be met. We can look unprofessional
to the customer, or we can negotiate a better schedule. If we
don't, and we start missing our deadlines, then we could end up
with a bad reputation to our market.
Note, there's nothing that stops you from being on the receiving end of
the product. I.e. you could be the customer. If you're the customer, and
the vendor promises a schedule which you think might not be met. What can
you do? Well, what I've seen done in the past is that the customer will
negotiate a price cut. Each month that the project is late, a percentage
is cut from the final price. Contracts are usually multi-phase, to make
scheduling and pricing easier.
I've left a job because of these issues. If your management is not smart
enough to do better than setting unrealistic schedules, I suggest you
start looking for something else as well.
> - changing customer requirements; and
Give them a schedule and make them pay. They can't add features and
expect to not cost resources. Also, if they change a feature, let them
know that it will change the schedule.
Most often, the features they request are 'good to haves'. Ask them if
you could add them in later. Otherwise, ask them what feature(s) can be
replaced. Customers often run into these issues in their own business as
well. So I'm sure they'll understand where you're coming from.
> - the tendency of management to undervalue any and all QA once the
> interface is pretty enough for their purposes.
This is where the integrated QA process comes into play. If you integrate
the testing into the development phase, then you get to decide when the
development is done. If you're not done with testing, don't say your done
with the software. Note, the external QA group can be used for just
verifying that the major features are working. The quality assurance is
performed within the development group.
Of course, you'll have to factor this additional work in the schedule.
Nothing comes for free.
By the way, the practices I listed are not just for code monkeys. They
are for the entire development team, including managers. I assume the
manager is part of the team. But that might be too much to ask. This is
why I put so much emphasis on the team. This implies that you shouldn't
hand a list of tasks to a programmer and tell them not to return until
everything is checked off. The team needs to work tightly together. Have
them sit next to each other if possible.
Jimen Ching (WH6BRR) jching at flex.com wh6brr at uhm.ampr.org
More information about the Programming