Is that not how every mud-hut building company works? ;-)

I only hope the senior dev^H^H^Hmud-hut builder isn't on the SLUG list...!

Rob.


On 6/10/05, Taryn East <[EMAIL PROTECTED]> wrote:
> 
> I am a c-programmer with five years of experience in a commercial environment,
> and have become increasingly aware of what I would consider to be a few
> failings in the technical processes of our company... but of course I am
> just the "junior" developer (don't seem to be able to shake that word from
> my official title) and my word is not considered to be more important to
> that of the senior developer that I work with (there are only two of us here
> - and the java guy who wisely keeps to himself).
> 
> I am, of course, under the standard NDA... so of course I can't publically
> rant about the problems we're having...
> 
> So I've written this *entirely fictional* story about two *entirely
> fictional* mud-hut builders for your general enjoyment (and my specific
> catharthic requirements).
> 
> This story consists of a conversation between a junior mud-hut builder(2)
> (of five years building experience) and a senior mud-hut builder(1) (of a
> guesstimated 20-30 years building experience) and takes place in the setting
> of the sprawling mud-cty in which the junior builder has been working
> for the past year and a half.
> 
> enjoy,
> Taryn East
> 
> PS - I'm actually writing up a formal review of the processes in question...
> I figure it'll either get me promoted, fired or ignored. In case of the
> latter two... does anyone know of any C-programming jobs going in a good
> company atm?
> 
> 
> 
> *** The parable of the mudpile ***
> Copyright Taryn East 2005, All rights reserved.
> 
> 
> 1- "Well, you grab a handful of mud and slap it onto the ground, then grab
> another handful and slap it on top, and keep doing that and eventually you
> have a huge, towering pile of mud, which our users can live in!"
> 
> 2- "...but the structure looks butt-ugly!"
> 
> 1- "Who cares what that looks like! The user is the only person that matters
> and they never see those bits."
> 
> 2- "Don't the builders have to work here? Don't you think it's a little
> stressful for them?"
> 
> 1- "Pshaw... Real Builders don't care about that - are you soft or
> something? Besides, we don't have time to build neatly and it works just
> fine, so quit your whining."
> 
> 2- "but what happens if we want to extend a mudhut? are these designs
> extensible?"
> 
> 1- "Sure it is! We just blow a hole through here and slap on a few more
> piles of mud, then clean up the bits from the hole-blowing. Oh and don't
> worry about those big cracks over there, we can just put a bit of mud-slip
> over them, you'll never notice the difference! Hmmm, maybe we'd better shore
> up this wall, it seems to be collapsing under the new weight (oops, didn't
> realise that was a weight-bearing wall)."
> 
> 2- "aren't these things documented anywhere? Even the walls don't have
> labels! is there no blueprint?"
> 
> 1- "No, why would we need that? It's obvious what it does if you just look
> at how it goes together! Aren't you a good enough builder that you can just
> see how it works without being told?"
> 
> 2- "Well, yes... but it takes me more time to do that than to read a
> blueprint... and if we had a blueprint we could have planned to strengthen
> that wall before we blew a hole through it!"
> 
> 1- "Look, we don't have time for all that, and we don't need it anyway, it
> works now, doesn't it? We don't need a planning document - I just figure out
> approximately what we're going to do, then flesh it out as I go along."
> 
> 2- "But what if we come across something that affects everything that you
> hadn't thought about? what if suddenly you notice that it's blocking
> an emergency accessway?"
> 
> 1- "Oh we just blow a hole through it and start that bit again... go back to
> the drawing-board, if you will"
> 
> 2- "But if we planned this stuff from the beginning, you wouldn't have had to
> do that - I'm sure we'd save more time if we didn't have to do all that
> stuffing around and rechanging everything to fit the new stuff... and it
> wouldn't be so unstable as it'd be planned from the beginning!
>    "Oh hey, look at this, isn't this new renovation blocking access to the
> mudhut behind it?"
> 
> 1- "The tenants can climb over that wall... oh, all right, that's an easy
> fix we can just build ourselves a bridge over this bit."
> 
> 2- "Now the bridge is blocking access to the mudhut on the other side, and
> it's even higher so they definitely can't climb over."
> 
> 1- "Well, I'll just give them a rocket-pack. See? We can solve any problem
> we need to..."
> 
> 2- "If we'd planned from the start we could have planned a common accessway
> for all of them to use... and that rocket-pack looks a little dangerous, I
> think it might have the potential to explode under certain circumstances."
> 
> 1- "What are you worried about? Most of the time it'll work just fine, you
> just need to handle it right."
> 
> 2- "Are you sure our users are going to always handle it just right? what if
> they're not trained in rocket-pack use? Maybe we should just provide a few
> safety switches, some checks for overheating or excessive gas-flow and a
> flash-back valve or something just in case..."
> 
> 1- <exasperated sigh> "Oh you're just needlessly complicating things. It is
> so unlikely we'd need it, that sort of thing happens so rarely, and it's just
> not worth the time to spend to do that - besides, it'd just make it
> needlessly complex. Sure, in a *perfect* world we'd have the luxury of
> installing thermostats or flow-regulators and flash-back valves, but this is
> not a perfect world and we just need to get the job done[1]. I think it's
> just fine to light the gas as it comes straight out of the bottle, it's
> never exploded the times that I've tested it! You're beginning to sound a
> bit green and naive, you know, like you're straight out of university![2]"
> 
> 2- "Fine, whatever. Anyway, can you tell me where the town hall is?"
> 
> 1- "Well, the town hall for these huts is that structure over there, but the
> huts on the south side needed a differently-shaped doorway to get the desk
> in, so I copied the architecture except for the door and built them another
> one for their use. Oh, and when that other builder was working on one of his
> developments he didn't realise we already had a town hall..."
> 
> 2- <sotto voce> "...I wonder if the lack of doco has anything to do with
> that..."
> 
> 1- "...so he built one on his own, which is in a completely different style."
> 
> 2- <sigh> "So we have three different town halls all performing roughly the
> same functions but with minor differences. Why don't we knock them all down
> and replace them with one *common* town hall and a couple of minor notaries
> that just look after the regional differences?"
> 
> 1- <look of horror> "But they're working as they are! And that'll cost us
> time and money!"
> 
> 2- "...but it's costing us more time and money to maintain three different
> ones, if a new common function is needed, we have to add it to all three!"
> 
> 1- "You *obviously* don't have the end-user in mind do you? it's not
> important for us to focus on fixing the architectural situation here, it's
> only important what the end-user sees!"
> 
> 2- "but if we fixed the way the architecture is laid out it'd be much
> quicker to get around between the important bits of town and fix stuff that
> the user does need... or to add new mudhuts for the users to use... and that
> sort of thing is something that the user notices because it'd take so much
> more time for new buildings to be built."
> 
> 1- "Our users are happy enough with how long it takes. We just need to throw
> a few more mud-hut builders at the problem... but that's all we need. I'm
> sure if we had more builders we'd have no problem getting everything we need
> done quickly."
> 
> 2- "But aren't there a bunch of other property developers down the road? If
> we can build our mudhuts faster thqn they can, then we'd certainly atract
> more users than them. Besides, you're not going to attract that many
> builders if the city is such a mess... it's just going to demoralise anyone
> working here."
> 
> 1- "Again with the wrong attitude! I've already told you - that stuff the
> user never sees anyway! The builders don't matter either, any Real Builder
> should be able to cope with this... you just must not be able to cope with
> stress or something."
> 
> 2- "But there *are* things that the user sees. The mudhuts don't have a
> common look and feel so the user gets different things depending on where
> they are in the city, and some of the buildings are begining to crumble to
> pieces they're so old! and they're covered in ugly patch-jobs from years of
> quick fix-up jobs, and that's even ignoring the old shag-pile and art-deco
> on some of the older mudhuts..."
> 
> 1- "We're getting rid of that - aren't you working on that next-generation
> paint project?"
> 
> 2- "Well yes but... the paint in some places is part of the structure of the
> walls... it's kind of hard to separate one from the other in places..."
> 
> 1- "oh stop whining already... so, we have old huts. As I said, it works, if
> we need to fix a crumbly bit, we just slop a bit *more* mud-slip over it...
> we don't have time for radical renovations right now..."
> 
> 2- "Yeah, but what happens when we *do* need to renovate for our users?
> Remember the big ASIC development that was so bad we had to bulldoze the
> lot? Only after it was razed to the ground could we start over from scratch.
> Some of those huts had the paint as an integral part of the load-bearing
> walls! But the problem is that we're still using that construction technique
> in some of our new mud-huts! Surely if we designed our new projects better
> it'd be easier to adjust to new requirements..."
> 
> 1- "Look, it's just quicker to paint the walls if you just dump it into the
> mud as you go along! Besides, the ASIC cleanup was a one-off... we won't
> ever need to go to *that* extreme again, surely!"
> 
> 2- "I don't know, some of those other old devlopments look a little
> bricked-in... if we ever needed to upgrade them like we wanted to upgrade
> the ASIC development..."
> 
> 1- "Look, you're getting out of scope again. The city is fine. Sure it has
> its "legacy buildings" but we'll deal with them when we find time. Our
> processes are much better these days!"
> 
> 2- "really? Last project I was on I was told to go extend the PCI building.
> I was told it was mostly done and that I should "just finish up the bits
> that hadn't been done yet".
>    "Of course it took me a while to figure out where everything *was* and
> how it all hooked up because there wasn't a clear blueprint so I had to go
> over the building inch-by-inch and figure out what each bit did. oh and the
> dumb-waiter to the FT building didn't have clear instructions either - it
> looked like it was written from the perspective of a servant working at the
> FT building, we had to figure out how to work it from our end.
>    "Once I figured out how it was all supposed to go together I started
> working on the bathroom out the back, and connected up the pipes where they
> were supposed to go, but when I turned the taps on, I found they only worked
> half the time - and only when you went through each room in the building in
> the right order, turning the taps on as you went... took me quite a while to
> fix all the plumbing to make the water accessible from any tap in the house
> independantly. It took me a *long* while, and needed a few walls moved as
> they were blocking the pipes, and I started to get vague hints that the
> site-manager thought I was taking too long. I got comments like "Boy I will
> be glad when the PCI building is done, our users are really eager to move
> in!"... which just added to the stress, of course.
>    "Eventually I came to realise that the half-a-building I'd inheritied
> didn't do half the stuff it needed to do, and even the bits it supposedly
> could do, didn't work as they should. For one thing, there certainly weren't
> any locks on any of the windows to stop burglars from getting in.
>    "Yet I sure get the feeling that how long it took must be reflecting
> poorly on how my building abilities are percieved by others - especially the
> site-managers as they couldn't tell how bad the building was to begin
> with... after all, they only had a brief look at the exterior and it looked
> about right..."
> 
> 1- "Well, why *did* you spend so much time refactoring the original hut?
> Sure it was a bit of a mess, but surely you could have just put some
> extensions on what was already there. I mean rebuilding the plumbing may
> make it look much prettier, but we just don't have that luxury! A few more
> pipes round the outside of the building would have worked too and would have
> been done much quicker for our users!
>    "Let me tell you a parable: there was a man who needed to build a new
> room on his house. He could have just knocked a hole in the wall and added a
> door and added the room as an extension, but instead he bulldozed the whole
> house to the ground and rebuilt the house from scratch, which cost him so
> much time and money!"[3]
> 
> 2- "That's not a fair comparison! To start with, it wasn't like the house
> was already working - I couldn't just build a new room onto it. Secondly, in
> the end it wasn't just another room, it turned out to be another 3 stories
> to add on top! Let me tell you that if you try to build a multi-storey
> building on top of a flimsy foundation meant for only a one-storey mud-hut,
> your multi-storey building is going to topple over sooner or later! Thirdly,
> it's not like I trashed the *whole* house, I reused some of the mud-bricks
> and the kitchen stayed the same... I just noticed we didn't need five
> different external stairwells when we only needed one common one and rebuilt
> that section around just one of the more sturdy stairwells so all the floors
> had access to it.
>    "Besides, this building is meant to be the centrepiece in the new Grand
> Vision for our devlopment company isn't it? The future rests on it working
> well and being extendible as time goes on - surely we should take the time
> to make it right!
>    "As a project, it was a dreadful schermozzle and I still think I should
> have just started from scratch and salvaged the useful bits instead of
> having to do multiple refactor-renovations of the original ad-hoc version.
> Of course now you've handed me another dodgy mudhut with the planned Bureau
> flats..."
> 
> 1- "Yeah, but that hut was just a quick-and-dirty mudpiling... to get it
> working"
> 
> 2- "Yeah, but the site-manager doesn't seem to realise that, he just looks
> at the outside and sees that water and power go in and the sewer is being
> used... he doesn't realise what a nightmare it is inside, and now he tells
> me to build another five storeys on top of that!"
> 
> 1- "Well, all you need to do is add another pipe around the outside to
> attach to the plumbing, and another for the sewer, and just extend it a bit
> more - you don't even need to add them as storeys on top, you can just add
> the rooms on the side..."
> 
> 2- "but I've already worked out a neater blueprint - one that will allow the
> building to be extensible to any height, and it'd be much easier to just do
> it this way... surely when we're basically right at the start of a new
> development we should do it right the first time."
> 
> 1- "Yes, but this building already works and your plans are untested... they
> might have a bug in them and you'd waste all that time testing and redoing
> bits that are already done."
> 
> 2- "Yeah, but won't be much extra time, and it'd be much easier to fix the
> place in the future, if you use my plans - for a start there's actually a
> blueprint which explains where everything is, so we can go straight to where
> the problem needs to be fixed.
>    "Secondly, there's a common modularity to the way the floors are
> constructed. The bathroom and kitchen are always over on the left - even if
> they have different fittings inside it means we only need one set of pipes
> and power conduits going up the middle of the building. I've also built it
> so that each floor can have their pipes sealed off form the other floors.
> This means that instead of the fifth floor taps only working if the fourth
> floor taps are also working (and so on down the building). We can completely
> seal off one level if the tenants move out, or even add a new level on top
> of the building if we need another one. We don't even need to worry about
> jerry-rigging up new sewer pipes around the outside of the building - you
> just do a few minor connections for water, sewerage and power, do the
> fittings on the inside and away you go!
>    "Anyway, what's this you said before about testing for bugs? our testing
> process is pretty haphazard when you think about it..."
> 
> 1- "What do you mean haphazard, we have clear processes! You test that it
> works, then the site-manager tests it, then the user-help manager tests it,
> then our "preferred users" get to move in and check if anything is broken,
> before letting in all the other users."
> 
> 2- "So where's the bit of paper that explains what we're all testing *for*?"
> 
> 1- "Oh, come-on, *you* know what you wrote so you should know what to test
> for... and the site-manager knows what the project is about, so he knows
> what it should do - what do you need a bit of paper for?"
> 
> 2- "Well actually I *don't* necessarily know what to test for. There's that
> bit of a mud-map that the site-manager drew for me when he handed me the
> project, but it only shows the basic overall outline of the building and a
> few things like "there should be a sewer pipe"... and nothing at all about
> what it should be like. I have to make up all the details as I go along...
> 
> 1- "...but, but... the site-manager isn't supposed to write a proper
> technical spec... he doesn't know how..."
> 
> 2- "Why that's right... that should have been your job...
>    <pregnant pause>
>    "As I was saying, there is no formally-accepted functional or technical
> specifications for each project. I've started writing these - those are the
> plans I mentioned for this bureau development... but if I just adapt
> something that's already partly-completed, my plans won't be meaningful and
> I never got plans for the building that was already there..."
> 
> 1- "I'm a senior architect - I don't need those plans, and you can just tell
> from my code what it's supposed to do. Anyway, most of our projects are too
> small to bother with going through all that trouble."
> 
> 2- "Even a small project could benefit by having some sort of guidelines on
> what is expected of it - and thus what to test for. Then we can later check
> that the project actually achieved all the goals... but only if we have them
> written down somewhere."
> 
> 1- "but the overall goals *are* written down, the details don't matter.
> Besides, if we miss anything, it'll get noticed at *some* stage of the
> testing process - that sort of thing is generally pretty obvious."
> 
> 2- "Well, not necessarily. Not if we haven't noted it down to make sure we
> remember to look for it. Do we really want to run the risk of something
> falling through our process until our *users* find the error?"
> 
> 1- "What's wrong with that? Our users should enjoy being part of the
> process... it makes them feel like they have "ownership" of the development
> process."
> 
> 2- "Hmmm, a user unexpectedly falling through the floor is not going to help
> our company image any - especially if we find out that it's because we're
> missing a necessary structural brace we just forgot to check for before we
> let them into the building."
> 
> 1- "Oh, so what you're saying is that you don't test thoroughly, is that it?"
> 
> 2- "No, I think I do the best I can, given the situation. But I'm only human
> - I make mistakes and I should have a bit of backup. Besides, I've gotten so
> used to the building that I don't even notice anymore that I tiptoe along
> the support-beam and don't ever walk over the unbraced-bits. I need a second
> pair of eyes to go over the stuff I've grown too used to seeing."
> 
> 1- "So what, you're expecting me or the site-manager to do your testing for
> you? But we're paid much more than you are, we shouldn't have to do that
> sort of grunt-work!"
> 
> 2- <frown> "Apart from the decidedly negative connotations inherant in what
> you just said... no, I don't expect *you* to do it. I merely mean that we
> should consider hiring a professional tester to sit in between me and the
> site-manager in the testing process..."
> 
> 1- "What, hire more people? we're having a hard enough time trying to find
> builders as it is for the jobs we already know need filling, and you want us
> to start thinking about *new* positions?"
> 
> 2- "Well... maybe if we cleaned up this city a little, we'd make it more
> attractive to good builders..."
> 
> 
> 
> 
> 
> 
> 
> 
> [1] alteration of a phrase our senior developer used when I tried to
> convince him of the benefits of modular programming and error-checking on
> magic-length char buffers...
> [2] the actual epithets he gave me in the same conversation... At that point
> I had 3.5 yrs of commercial experience...
> 
> [3] actual parable the senior developer told me when I suggested refactoring
> part of the code... clearly demonstrating that he didn't understand what
> "refactoring" meant - or that he'd asked me to do more than just add a
> single room. It also didn't take into account the sprawling horrors that had
> eventuated from five years of these kinds of extensions...
> 
> 
> 
> 
> 
> 
> --
> This .sig temporarily out-of-order.
> We apologise for any inconvenience
>                     - The Management
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 


-- 
Rob Sharp

  email/jabber: [EMAIL PROTECTED]
  web: http://sharp.id.au
  pgp: 0E2C C63B BA04 DEB4 7CC0 84FD 17E3 6AA4 87FB 62DF
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to