 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
--
~Mike
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
>
> I'm working on one right now.
My God have mercy on your soul.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> 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 believe any software eventually reach that stage. The more you add,
the more complex, the more resistent to change, the more ugly, the more
fragile to subtle bugs. Its inertial mass at work...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmail com> wrote:
> I believe any software eventually reach that stage. The more you add,
> the more complex, the more resistent to change, the more ugly, the more
> fragile to subtle bugs. Its inertial mass at work...
And it certainly doesn't help when project managers get evangelized into
believing that methodologies like "rapid prototyping" will help making
better programs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I believe any software eventually reach that stage. The more you add,
>> the more complex, the more resistent to change, the more ugly, the more
>> fragile to subtle bugs. Its inertial mass at work...
I would argue that it varies depending on what precisely you're trying
to add, how carefully you add it, how well the program was designed in
the first place, how often you go about code reorganisation / tidy-up,
and so forth. I don't think it's as simple as "all code eventually
becomes unmaintainable" (although there's certainly a very considerably
tendency in that direction).
> 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.
But no, Rapid Application Development and similar management buzzwords
do not magically solve computer programming. (Quite the contrary,
usually...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 8:21 AM, nemesis wrote:
>
> I believe any software eventually reach that stage. The more you add,
> the more complex, the more resistent to change, the more ugly, the more
> fragile to subtle bugs. Its inertial mass at work...
>
In our case I think it's a matter of requirements drift and feature
creep making it so fragile. We've done so many "pull this block out and
place it in a different area of the stack" changes lately, that the
software really is starting to resemble Jenga.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 10:03 AM, Darren New wrote:
> off of managing, and have employees who are decent coders but shit
> programmers, and still think you can create something usable. Which
I'm curious. What is the distinction between a coder and programmer, here?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/10/2010 10:52 AM, Invisible wrote:
> - 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?
>
Oh, yes.. and while you're at it, would it be too difficult to add ∂, ∆,
σ, λ, θ, ω? I really thing feature ω will be the ultimate feature for
this application!
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> - 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?
>
> Oh, yes.. and while you're at it, would it be too difficult to add ∂, ∆,
> σ, λ, θ, ω? I really thing feature ω will be the ultimate feature for
> this application!
Sure. Just for the love of God, don't ask me to make it a web
application and expect it to work in IE /and/ standards-compliant
browsers... >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 11/11/2010 15:17, Mike Raiford nous fit lire :
> On 11/10/2010 10:03 AM, Darren New wrote:
>
>> off of managing, and have employees who are decent coders but shit
>> programmers, and still think you can create something usable. Which
>
> I'm curious. What is the distinction between a coder and programmer, here?
>
Along the same as between a writer and an author, for literacy.
Knowing the alphabet is not enough to be Victor Hugo even if Victor Hugo
did know the alphabet too.
Alas, so many people thinks that they can make a database because they
managed to make three columns on an excel-sheet.
They succeed to make an hello world in whatever language...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford escreveu:
> On 11/10/2010 10:03 AM, Darren New wrote:
>
>> off of managing, and have employees who are decent coders but shit
>> programmers, and still think you can create something usable. Which
>
> I'm curious. What is the distinction between a coder and programmer, here?
a coder types away careful algorithms of how to do something as in a spec.
a programmer receives a half-baked spec in natural language and has to
translate that to l33tsp34k at the same time magaging to map the
instructions into the computational model already in place.
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> 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.
Sometimes (often?) rewriting the whole thing from scratch would indeed
take much longer than adding the small new feature. However, the rewrite
would benefit the project in the long run, as subsequent features would
become easier to add, saving in the total time.
However, I assume it's difficult to convince a boss of the fact that
"if we spend a month rewriting the whole thing from scratch now, we will
save several months of work later".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
>
> Sometimes (often?) rewriting the whole thing from scratch would indeed
> take much longer than adding the small new feature. However, the rewrite
> would benefit the project in the long run, as subsequent features would
> become easier to add, saving in the total time.
Not to mention the amount of debugging time you'd save...
> However, I assume it's difficult to convince a boss of the fact that
> "if we spend a month rewriting the whole thing from scratch now, we will
> save several months of work later".
Unfortunately, it tends to be quite hard to measure "time we didn't have
to spend because we did X last year"...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Mike Raiford escreveu:
>> On 11/10/2010 10:03 AM, Darren New wrote:
>>
>>> off of managing, and have employees who are decent coders but shit
>>> programmers, and still think you can create something usable. Which
>>
>> I'm curious. What is the distinction between a coder and programmer,
>> here?
>
> a coder types away careful algorithms of how to do something as in a spec.
> a programmer receives a half-baked spec in natural language and has to
> translate that to l33tsp34k at the same time magaging to map the
> instructions into the computational model already in place.
>
Plus, the coder writes code. The programmer writes programs. If you think
the only part of a program is the code, then you're part of the problem.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Oh, yes.. and while you're at it,
My favorite was when the boss asked me to do a program for an HR manager to
use to manage HR benefits. I said "OK, about six weeks." Four or five weeks
in, he asks how long it would take to change the program to let the
employees use it instead. He was rather shocked when I said "About eight weeks."
Yeah, there's a slight difference between the requirements to allow a teller
to take money out of your account on request and an ATM.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
