Home > Archive > Software Engineering > February 2006 > you are joking - right?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
you are joking - right?
|
|
| bebop o'saurus 2006-02-08, 7:00 pm |
| please, can any of you comment on the following directive repeated often by
the lead programmer of the dev team i work with:
"...[the software product] doesn't have to work; it just needs to
integrate..."
that directive is repeated often; most recently, 2 days before functional
testing was about to start.
btw, pls don't try to sell me on your favorite methodology; my mind is
firmly made up on what i prefer - thank you very much (in a nutshell:
iterative/incremental development).
it's just that i am new to this particular team and i just can't get my head
around what the rationale for this kind of directive might be (the obvious
time constraints and unrealistic schedules notwithstanding). i don't want to
jump to conclusions and make any rash decisions. so i wondered if this is a
widely-followed practice? i'm also wondering if i really want to be a part
of a team that has that as their mantra.
thanks in advance for you replies.
| |
| Roy Smith 2006-02-08, 7:00 pm |
| "bebop o'saurus" <bebop@lingoVEGANcoder.com> wrote:
> please, can any of you comment on the following directive repeated often by
> the lead programmer of the dev team i work with:
>
> "...[the software product] doesn't have to work; it just needs to
> integrate..."
My guess is the lead programmer's MBOs(*) say, "integration of [software
product] 100% complete". If wasting time making it work makes him miss his
integration deadline, he's screwed himself out of his quarterly bonus.
* MBO = Mediocrity By Objective
| |
|
| On=20Sat,=204=20Feb=202006=2017:48:59=20
UTC,=20"bebop=20o'saurus"=20<bebop@lingoVEGANcoder.com>=20wrote:
> =20please,=20can=20any=20of=20you=20comm
ent=20on=20the=20following=20directive=2
0repeated=20often=20by=20
> =20the=20lead=20programmer=20of=20the=20
dev=20team=20i=20work=20with:
>=20
>=20=20=20=20=20=20"... [the=20software=20product]=20doesn't=20h
ave=20to=20work;=20it=20just=20needs=20t
o=20
>=20integrate..."
>=20
> =20that=20directive=20is=20repeated=20of
ten;=20most=20recently,=202=20days=20bef
ore=20functional=20
>=20testing=20was=20about=20to=20start.
=20=20That=20wouldn't=20fly=20with=20any
=20of=20the=20groups=20I've=20worked=20w
ith.=20=20Yes,=20right
before=20turning=20the=20product=20over=
20to=20a=20test=20group=20it=20might=20b
e=20a=20bit=20more=20
important=20to=20make=20sure=20the=20pro
duct=20integrates=20(builds?)=20and=20not
necessarilty=20be=20complete=20or=20corr
ect. =20=20I'd=20be=20sure=20to=20let=20the=2
0testers=20know
so=20that=20they=20don't=20write=20lots=
20of=20useless=20defects=20against=20cod
e=20you=20really
aren't=20claiming=20complete=20anyway.
=20=20My=20standards=20for=20development
=20state=20that=20the=20build=20is=20nev
er=20broken,
features=20are=20complete=20and=20tested
=20before=20going=20to=20validation,=20a
nd=20any
product=20released=20must=20be=20support
able=20in=20the=20field.=20=20There=20are=20times
that=20groups=20do=20choose=20to=20turn=
20over=20code=20to=20validation=20that=2
0is=20not
complete. =20=20That=20requires=20some=20negotiati
on=20and=20cooperation=20between
the=20groups=20to=20limit=20any=20unnece
sary=20work. =20=20Hopefully=20you=20can=20talk=20wit
h
your=20leadership=20later=20and=20try=20
to=20understand=20why=20he/she=20has=20those
goals. =20=20Then=20give=20your=20input=20on=20
how=20the=20process=20might=20be=20bette
r.
I=20enjoy=20having=20developers=20that=2
0can=20think=20and=20have=20opinions=20o
n=20my
team.=20=20... my=20worst=20team=20leader=20had=20the=2
0mantra=20"Can't=20we=20just=20all
get=20along".
=20=20David
| |
| JXStern 2006-02-08, 7:00 pm |
| On Sat, 4 Feb 2006 17:48:59 -0000, "bebop o'saurus"
<bebop@lingoVEGANcoder.com> wrote:
>please, can any of you comment on the following directive repeated often by
>the lead programmer of the dev team i work with:
>
> "...[the software product] doesn't have to work; it just needs to
>integrate..."
I just worked in a situation where that was apparently the directive
("it just has to compile and run without crashing"). When I told the
dufus I needed half a day for unit test, he stood there like I had
just requested time for a round of golf. By no coincidence at all,
every piece of code I touched there had serious bugs.
Somewhat satisfyingly, a w later the project manager there was
history, probably not directly because of this, but probably
indirectly.
Quality software is an entirely different exercise from crap software.
Quality has to be built in, and unit test is a crucial part of
delivering quality product.
What do you bet that, in your situation, the project plan has time for
system test, but no time for repair and refactoring?
J.
| |
| Roy Smith 2006-02-08, 7:00 pm |
| JXStern <JXSternChangeX2R@gte.net> wrote:
> every piece of code I touched there had serious bugs.
You know, there's several ways to interpret that statement ;-)
| |
|
| bebop o'saurus wrote:
> "...[the software product] doesn't have to work; it just needs to
> integrate..."
>
> that directive is repeated often; most recently, 2 days before functional
> testing was about to start.
Hmm. Someone is sweeping the dirt under the rug, and hoping the project's
deadline has a lot of float built in...
> btw, pls don't try to sell me on your favorite methodology
Remember to use Big Bang Testing followed by a "just clean it up enough to
pass" phase!
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
|
| bebop o'saurus wrote:
> btw, pls don't try to sell me on your favorite methodology; my mind is
> firmly made up on what i prefer - thank you very much (in a nutshell:
> iterative/incremental development).
Suppose for a moment that you were a junior and this 'lead' a senior.
Now why do you prefer incremental development (meaning daily builds,
frequent releases and such)? Maybe, in your juniority, you worked with a
team that followed such practices.
If so, it's a testament to the advanced power of these techniques that you,
as a junior, are already senior in experience to someone who has "been
around this block before, and knows what's important already".
A little knowledge is a dangerous thing!
> i'm also wondering if i really want to be a part of a team that has that
> as their mantra.
Change your organization or change your organization!
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
|
| Roy Smith wrote:
> My guess is the lead programmer's MBOs(*) say, "integration of [software
> product] 100% complete". If wasting time making it work makes him miss
> his
> integration deadline, he's screwed himself out of his quarterly bonus.
>
> * MBO = Mediocrity By Objective
Just in case anyone thinks Roy is kidding here, _Management_ by Objective is
indeed a common practice. It fits hand-in-glove with Taylorism,
time-and-motion studies, job-cost accounting, etc. You set a metric goal,
and reward managers who exceed that goal.
An excellent example here is the USSR under Kruszchev or Brezhnev. You
reward a regional manager for producing lots of steel. Then nobody needs the
steel (no just-in-time inventory or other Lean practices to pull for that
steel), and you use the extra steel to build more steel mills.
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Martin Brown 2006-02-08, 7:00 pm |
| Roy Smith wrote:
> "bebop o'saurus" <bebop@lingoVEGANcoder.com> wrote:
>
>
> My guess is the lead programmer's MBOs(*) say, "integration of [software
> product] 100% complete". If wasting time making it work makes him miss his
> integration deadline, he's screwed himself out of his quarterly bonus.
>
> * MBO = Mediocrity By Objective
It's a direct corollary of the maxim "what you measure gets controlled".
It is even more pernicious where management bonuses are involved.
Presumably the shop also operates a ship it and be damned policy too?
Regards,
Martin Brown
| |
| Andrew McDonagh 2006-02-08, 7:00 pm |
| bebop o'saurus wrote:
> please, can any of you comment on the following directive repeated often by
> the lead programmer of the dev team i work with:
>
> "...[the software product] doesn't have to work; it just needs to
> integrate..."
>
> that directive is repeated often; most recently, 2 days before functional
> testing was about to start.
>
> btw, pls don't try to sell me on your favorite methodology; my mind is
> firmly made up on what i prefer - thank you very much (in a nutshell:
> iterative/incremental development).
>
> it's just that i am new to this particular team and i just can't get my head
> around what the rationale for this kind of directive might be (the obvious
> time constraints and unrealistic schedules notwithstanding). i don't want to
> jump to conclusions and make any rash decisions. so i wondered if this is a
> widely-followed practice? i'm also wondering if i really want to be a part
> of a team that has that as their mantra.
>
> thanks in advance for you replies.
>
>
At my last employers, another team was singing their own praises that
they were on time with their release. Then they used the phrase 'code
complete' which immediately rang bells with me. So asking them what they
meant by that, it turned out that they had finished 'all necessary
coding and produced a build' for the release. And further questioning
revealed thats all they meant, they had not even ran the software
themselves, never mind done any kind of testing. And yet here they are
proudly claiming to have made a release on time.
The  dest part was the managements response - they just accepted it.
Needless to say I wasn't impressed.
| |
| bebop o'saurus 2006-02-08, 7:00 pm |
| > Presumably the shop also operates a ship it and be damned policy too?
the shop gets paid based on "function points". my understanding of that is,
mgt agrees upfront with the client that the shop will deliver software with
such-and-such functionality (regardless of whether developers work 40
hours/w or 80 hours/w to produce it). i believe there are also
contractually-agreed delivery milestones with built-in penalities if
milestones aren't hit. so obviously, we have to deliver on time AND the
stuff has to work. this particular lead programmer seems to have fixated on
only the time aspect.
i don't want to come off as if i am picking on the guy, but the fact is he
has worked for this particular shop for 7 years as a java programmer and he
has never written a single junit test! the same thing goes for most of the
other developers at this company.
| |
| xpyttl 2006-02-08, 7:00 pm |
| "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote in message
news:ds4lvs$6af$1@newsg4.svr.pol.co.uk...
> It's a direct corollary of the maxim "what you measure gets controlled".
> It is even more pernicious where management bonuses are involved.
It sort of sounds like you have a problem with the customer wanting to pay
for what he gets. Do you really believe that the customer owes you a
living?
...
| |
| xpyttl 2006-02-08, 7:00 pm |
| "Phlip" <phlipcpp@yahoo.com> wrote in message
news:8peFf.4854$ur7.2065@newssvr33.news.prodigy.com...
> Change your organization or change your organization!
Philip, I like that one. That is often good advice. (I almost said always,
but I hate to say always or never!)
...
| |
| H. S. Lahman 2006-02-08, 7:00 pm |
| Responding to O'saurus...
> please, can any of you comment on the following directive repeated often by
> the lead programmer of the dev team i work with:
>
> "...[the software product] doesn't have to work; it just needs to
> integrate..."
>
> that directive is repeated often; most recently, 2 days before functional
> testing was about to start.
Kind of like: the product doesn't need to work; it just needs to pass
pass the tests...
[Sorry Phlip. I couldn't resist. The Devil made me do it.]
To give the LP a modicum of credit, it depends on what one means by
'work' and 'integrate' and what sort of software is being built. For
example, if you are providing hardware device drivers in a hybrid
system, then hardware integration is not complete until the hardware can
be demonstrated to work properly within the system's usage context.
However, that does not require the device drivers to work properly for
every conceivable uses of the hardware. One can extend that notion of
successful integration to almost any sort of software integration.
IOW, the LP's intent /might/ be that the software only needs to work
well enough to integrate properly into the system in hand. OTOH, the
LP's bonus may only depend on some looser notion of 'integration' and
not correctness. B-)
> btw, pls don't try to sell me on your favorite methodology; my mind is
> firmly made up on what i prefer - thank you very much (in a nutshell:
> iterative/incremental development).
FWIW, I usually find it useful to distinguish between the creative and
non-creative facets of software development. To do that one needs to
distinguish between repeatable development activities like IID and
unique problem solving activities like design. The way one goes about
such activities is quite different so one would like different
characterization semantics. Using 'methodology' for driving unique
intellectual content and 'process' for driving the more mundane,
repeatable activities works quite well.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH
| |
|
| bebop o'saurus wrote:
>
> the shop gets paid based on "function points". my understanding of that
> is, mgt agrees upfront with the client that the shop will deliver software
> with such-and-such functionality (regardless of whether developers work 40
> hours/w or 80 hours/w to produce it).
How frequently do they create a fully working, tested version? Quarterly?
Another non-incremental symptom here is the project depends on "Big
Requirements Up Front", instead of just-in-time requirements, so they have
an irrelevant but contractual target for everything.
To not work 80 hours a w, throw away the features that nobody needs.
http://c2.com/cgi/wiki?IncoherentRewardStructures
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
|
| H. S. Lahman wrote:
> Kind of like: the product doesn't need to work; it just needs to pass pass
> the tests...
>
> [Sorry Phlip. I couldn't resist. The Devil made me do it.]
That's still better than the alternative!
(For the newbs who don't understand our banter, if you attach the test
writing process to the requirements gathering process, then you can
efficiently use the tests to enforce all your features while rapidly
changing code. If you don't, then tests will support a very high velocity in
a random direction.)
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| bebop o'saurus 2006-02-08, 7:00 pm |
|
"JXStern" <JXSternChangeX2R@gte.net> wrote in message
news:a6hau1pvlh939rflgkajrv2tt8lv9d57aa@
4ax.com...
> On Sat, 4 Feb 2006 17:48:59 -0000, "bebop o'saurus"
> What do you bet that, in your situation, the project plan has time for
> system test, but no time for repair and refactoring?
>
for system test, yes definately. for refactoring, definately no (not
explicitly on paper anyway; but i am in the habit of doing my own
refactoring proactively anyway, so...).
another curious thing about this project (unlike any other i've been
involved in) is the project mgr and lead programmer seem to be playing the
project plan close to their chests. in other projects i have worked on (even
at this same company) some form of the project plan is either distributed in
some form or another (electronic or hard copies) or published somewhere for
all to see. i imagine if i asked to see it, i'd be shown it no problem; to
be frank i hadn't really thought about that until now. typically, i don't
mind being shielded from that sort of thing as long as i feel confident that
the lead programmer knows what he's doing. first thing tomorrow, i am going
to ask to see the project plan.
| |
|
| bebop o'saurus wrote:
> ...i imagine if i asked to see it, i'd be shown it no problem; to be frank
> i hadn't really thought about that until now. typically, i don't mind
> being shielded from that sort of thing as long as i feel confident that
> the lead programmer knows what he's doing. first thing tomorrow, i am
> going to ask to see the project plan.
Would you like a cyanide capsule to go with that?
Your best bet is to quietly set a good example. Use test-driven development
on your own features, and build a test batch that you run every morning and
evening. The problem with this strategy is it might insulate your leaders
from the effects of their leadership. The benefit is you will have a low
defect rate and high accountability.
Let management sort their own problems out themselves. I'm aware this
strategy might lead to going down with the ship, but it's better than being
made a scapegoat!
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| Peter K. 2006-02-08, 7:01 pm |
| "Phlip" <phlipcpp@yahoo.com> writes:
> Your best bet is to quietly set a good example. Use test-driven development
> on your own features, and build a test batch that you run every morning and
> evening. The problem with this strategy is it might insulate your leaders
> from the effects of their leadership. The benefit is you will have a low
> defect rate and high accountability.
I reckon co-worker-induced bugs will also show up... which is probably
detrimental to the OPs political health.
Ciao,
Peter K.
--
"And he sees the vision splendid
of the sunlit plains extended
And at night the wondrous glory of the everlasting stars."
| |
|
| Peter K. writes:
>
>
> I reckon co-worker-induced bugs will also show up... which is probably
> detrimental to the OPs political health.
Absolutely. When their changes break my tests, I get dinged for taking time
to repair the tests, or I comment out the test and their quality drops.
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
| |
| JXStern 2006-02-08, 7:01 pm |
| On Sun, 5 Feb 2006 12:53:02 -0000, "bebop o'saurus"
<bebop@lingoVEGANcoder.com> wrote:
>
>the shop gets paid based on "function points". my understanding of that is,
>mgt agrees upfront with the client that the shop will deliver software with
>such-and-such functionality (regardless of whether developers work 40
>hours/w or 80 hours/w to produce it). i believe there are also
>contractually-agreed delivery milestones with built-in penalities if
>milestones aren't hit. so obviously, we have to deliver on time AND the
>stuff has to work. this particular lead programmer seems to have fixated on
>only the time aspect.
Depends on what you mean by, "deliver".
In any plan where "deliver" means sign a piece of paper swearing it's
done, but the code does not immediately enter production, you're going
to be playing a game of liar's poker.
Does the customer *immediately* run his own tests on "delivered" code?
Is there any blowback if bugs are found there? Or is the customer
planning to trust the delivery statements and plans to slip the
software immediately into production, when the 27th module has been
"delivered"? Sounds like the latter. Good luck to them. When's the
happy day?
J.
| |
| Martin Brown 2006-02-08, 7:01 pm |
| xpyttl wrote:
> "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote in message
> news:ds4lvs$6af$1@newsg4.svr.pol.co.uk...
>
>
> It sort of sounds like you have a problem with the customer wanting to pay
> for what he gets. Do you really believe that the customer owes you a
> living?
What on earth makes you think that? I am pro metrics with the proviso
that they must be properly aligned with the true business objectives
(and not orthogonal or still worse in opposition).
What I am saying here is that the product delivered to the customer
should have the real functionality specified and not just a shallow
outer veneer sufficient to fool the suits into signing it off and paying
up on delivery. There are almost always nasty repercussions when
unfinished buggy code is shipped prematurely. There can still be reasons
why it *has* to happen if it is a choice of that or going bust. But it
should not be routine.
The OP's description sounded very much like the throw it over the wall
and let integration and system testing sort it out school of product
development. This is not a process model that I can subscribe to.
You get a more coherent product when at least part of the team follows
the project through all phases. Ownership helps to raise quality.
Regards,
Martin Brown
| |
| Wayne Woodruff 2006-02-08, 7:01 pm |
|
>please, can any of you comment on the following directive repeated often by
>the lead programmer of the dev team i work with:
>
> "...[the software product] doesn't have to work; it just needs to
>integrate..."
>
Reminds me of a project manager I once worked for who's answer to ANY
technical question was ... "Don't worry about it, all the thinking's
been done"
Wayne Woodruff
http://www.jtan.com/~wayne
| |
| xpyttl 2006-02-08, 7:01 pm |
| "Martin Brown" <|||newspam|||@nezumi.demon.co.uk> wrote in message
news:ds72st$o2d$1@news6.svr.pol.co.uk...
> What on earth makes you think that? I am pro metrics with the proviso
Sorry. I was sort of getting the subtext that there was something evil
about expecting the development team to actually be accountable.
> that they must be properly aligned with the true business objectives
and this is absolutely right, although harder than it sounds
> You get a more coherent product when at least part of the team follows the
> project through all phases. Ownership helps to raise quality.
I'm not convinced of this. Although clearly when fokks feel "bought in"
they will tend to be a little more careful, this approach has a huge
productivity cost. I wonder if the resulting pressure to fix the
productivity doesn't have a more negative effect on the quality. While I
have seen the quality rise following fragmentation of the team, this is
admittedly anecdotal, and I haven't run the experiment. Would be kind of
interesting to try to actually collect the data.
But that doesn't change the fact that you not only need to deliver function
points ... those functions need to align with the business goals. It seems
a little hard to believe that OP's organization is as badly broken as it
seems, but it is pretty clear it is broken, nonetheless.
...
| |
|
| Wayne Woodruff wrote:
> Reminds me of a project manager I once worked for who's answer to ANY
> technical question was ... "Don't worry about it, all the thinking's
> been done"
There are those who call that "making irreversible decisions before getting
the best data".
If he or she actually did that...
--
Phlip
[url]http://www.greencheese.org/ZLand[/url] <-- NOT a blog!!!
|
|
|
|
|