 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> But no, Rapid Application Development and similar management buzzwords
> do not magically solve computer programming.
Actually, I come to the conclusion that if you look at most of the XP and
other Agile-style stuff, the main thrust is to let management slack off of
managing, and have employees who are decent coders but shit programmers, and
still think you can create something usable. Which might work if there's
only one customer for the software.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> > And it certainly doesn't help when project managers get evangelized into
> > believing that methodologies like "rapid prototyping" will help making
> > better programs.
> Uh, no, not really.
> Rapid prototyping /can/ be very useful for figuring out exactly what you
> do and don't want from an application. And iterative prototyping (which
> isn't the same thing) can be useful for trying out design alternatives.
Well, that's the theory, and that's why so many project managers get
infatuated with the idea. Also, it helps catching design mistakes early
in the project, saving a lot of work (because the later in the project a
mistake is caught, the harder and more time-consuming it is to fix it).
At least in theory. The practice, however, can be quite ugly. What usually
happens in reality is something like this:
First the programmer is given a basic ascetic description of the program,
and the programmer makes a small prototype. Then new ideas start pouring in,
"add this and this... and let's also try this small thing... add a button
that does this". Each time a new small feature request comes in, does the
programmer start from scratch, or does he simply add the feature to the
existing prototype? Most probably he won't start from scratch just to add
a new small feature.
Thus the project advances. What started as a small, lean&clean prototype,
with nice little modules and functions, starts slowly but steadily growing,
as more and more small features are added and modified. Almost imperceptibly
the program grows into a humongous behemoth full of spaghetti code. The nice
200-line modules grow into huge 2000-line modules (and that's if the
programmer is being conservative and frequently splitting features into
new modules), and the dependencies between modules become more and more
complicated.
At some point the program will have become a monster. Basically a huge
pile of small prototypes built onto previous prototypes, small kludges
added to previous kludges. The time has come to throw everything to the
trash and start from scratch. However, there are these things called
deadlines. Managers want results. They don't want programmers spending
the next two months starting the project from scratch. This is especially
so because the managers want *rapid* prototyping. They don't want to wait
two months for a new prototype.
So the programmer keeps adding new features to the monster. This is
becoming increasingly laborious, but they try to cope. The end result is
a horrible and unmaintainable mess. Probably more horrible than what would
have been done with a more traditional development model.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Rapid prototyping /can/ be very useful for figuring out exactly what you
>> do and don't want from an application. And iterative prototyping (which
>> isn't the same thing) can be useful for trying out design alternatives.
>
> Well, that's the theory, and that's why so many project managers get
> infatuated with the idea. Also, it helps catching design mistakes early
> in the project, saving a lot of work.
Yeah, that's the theory.
> At least in theory. The practice, however, can be quite ugly. What usually
> happens in reality is something like this:
From what I've seen, the theory goes wrong when one of the following
happens:
- You throw together a quick "prototype", which somehow becomes "the
final application", and you end up having to actually "support" this thing.
- The program gets so many feature requests that the entire scope of the
program is fundamentally altered. Sometimes a program designed for X
ends up having to do Y instead (where X and Y aren't really related),
but a much more common paradigm is where a program designed to do X ends
up being required to do X, Y, Z, W, K, R, J, L, S and V. And maybe you
could add F as well? By the weekend?
- Management think that "rapid prototyping" means "we can get away with
one tenth of the usual development time and one hundreds of the manpower
and still produce a working product". Uh, no, no you cannot.
> The time has come to throw everything to the
> trash and start from scratch. However, there are these things called
> deadlines. Managers want results. They don't want programmers spending
> the next two months starting the project from scratch. This is especially
> so because the managers want *rapid* prototyping. They don't want to wait
> two months for a new prototype.
Ah yes, the source of a million bugs...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 6:47 AM, Invisible wrote:
> http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
>
> "The old [engine] had grown to resemble the closing stages of a game of
> Jenga, in which making any change was a delicate operation that risked
> bringing the whole edifice crashing down. In particular, there were a
> dozen open bugs [...] that I had no idea how to fix."
>
> I think that's a really amusing quote. How many of you have worked on
> programs that look like "the closing stages of a game of Jenga"? :-D
I have a slew of them I have to support
They started as a very good idea that was decently cleanly coded, but
then ad-hoc requirements and programming made them into the beast that
they are.
I got to the point where I told my boss I could not change the programs
any more. We had a couple of incidents where his 'request/requirement'
caused the program to overwrite it's own data. Basically a couple of
days worth of work to re-do.
Really scary - especially when the bogus data makes it out to the clients.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> First the programmer is given a basic ascetic description of the program,
> and the programmer makes a small prototype. Then new ideas start pouring in,
Yes, this exactly.
And worse, the request comes from a customer who "will buy it if we put this
in." But it takes three weeks to put it in, and the customer waits 2 weeks
and changes their mind, because the customer didn't really want to buy it
anyway but didn't want to tell the pushy salesman to go stuff it.
So you not only have a whole bunch of bags on the side (which is the old
timer's name for such features), but you have a whole bunch of bags half of
which are leaking.
I can't even say how many projects I've worked on that weren't even spec'ed
out enough for the person asking for the project to realize it's impossible
to implement. Stuff like sample reports with amounts and totals marked as
"$XXX.XX" in the example, with calculations that mean the grand total at the
bottom right can't be both the sum of the column above and the sum of the
row to the left.
> Thus the project advances. What started as a small, lean&clean prototype,
> with nice little modules and functions, starts slowly but steadily growing,
I *did* work in one place briefly once, where each project timeline would be
estimated based on "is this a one-off, or a production system? Are you
asking this question once, or will you ask again." Asking once might take a
week to code, while asking in production would take six to eight weeks.
The cool thing was, after the one-off, you ran the program, took it to the
person that asked for it, and if they approved, you got them to sign off on
the timesheet. Then you went back and deleted the code.
When they come back the next month and say "I need that report again", you
get to say "It'll take a week this time also."
That was back when managers didn't think they could dictate development times.
Nowadays, where I work, nobody even starts writing the spec until after
they've decided when the feature will be released. I kid you not.
Only occasionally have I managed to convince a boss it'll be faster to
rewrite this from scratch than it will be to add the feature you're asking for.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 8:39 AM, Mike Raiford wrote:
> On 11/10/2010 5:47 AM, Invisible wrote:
>
>> I think that's a really amusing quote. How many of you have worked on
>> programs that look like "the closing stages of a game of Jenga"? :-D
>
> I'm working on one right now.
Curse you! I was going to say that!
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 6:47 AM, Invisible wrote:
> http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7
>
> "The old [engine] had grown to resemble the closing stages of a game of
> Jenga, in which making any change was a delicate operation that risked
> bringing the whole edifice crashing down. In particular, there were a
> dozen open bugs [...] that I had no idea how to fix."
>
> I think that's a really amusing quote. How many of you have worked on
> programs that look like "the closing stages of a game of Jenga"? :-D
If you don't manage a project properly, anything non-trivial can turn
into that.
I suppose project managers should remember that whenever the
requirements change, the project goes back to square one. And they
should promise accordingly. And their bosses should accept this.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/11/2010 07:36 PM, Darren New wrote:
> That was back when managers didn't think they could dictate development
> times.
This is probably reason #1 why software projects fail.
Today it seems that management think that working out how long something
will take is as simple as plucking a number of out thin air. This leads
directly to absurdities such as...
> Nowadays, where I work, nobody even starts writing the spec until after
> they've decided when the feature will be released. I kid you not.
>
> Only occasionally have I managed to convince a boss it'll be faster to
> rewrite this from scratch than it will be to add the feature you're
> asking for.
QED.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I think that's a really amusing quote. How many of you have worked on
>> programs that look like "the closing stages of a game of Jenga"? :-D
>
> If you don't manage a project properly, anything non-trivial can turn
> into that.
>
> I suppose project managers should remember that whenever the
> requirements change, the project goes back to square one. And they
> should promise accordingly. And their bosses should accept this.
Amen!
Interestingly though, the project being referred to here is an open
source system that (AFAIK) nobody even gets paid to work on. So while
it's legendary that commercial applications end up looking like
spaghetti soup due to ridiculous specs, absurd deadlines or the
employment is incompetent programmers, none of those would seem to apply
here. So how does an open source project end up like this?
Well, I can think of a couple of reasons:
- There are approximately 3 active developers (with a larger cloud of
occasional contributors floating around the outside). I don't think
there's anybody really "in charge" of "project managing" the thing as
such, development just kind of "happens". And there's always a task list
the size of a small moon, with nowhere near enough people to attack it.
- This isn't some enterprisy system that just pushes data around in a
database. This is a compiler. It involves serious heavy-metal logic
theory and so forth, which is quite easy to get wrong.
- It has /a lot/ of "experimental" features. The design of these can and
does change from time to time.
The "game of Jenga" they just replaced wasn't just a case of deleting
the code and rewriting it from scratch. Rather, a couple of PhDs spent
about 3 years designing a consistent logical theory for how all the
features should work. Actually /implementing/ this was the easy part.
It seems likely that this is an activity which will only get repeated in
the future...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 7:44 AM, Invisible wrote:
>>> I think that's a really amusing quote. How many of you have worked on
>>> programs that look like "the closing stages of a game of Jenga"? :-D
>>
>> I'm working on one right now.
>
> My God have mercy on your soul.
I'm beginning to wonder if I've died and gone to Hell...
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
