Comment On I Wish I Worked for PEDANT

I wonder what

production will come to awe'll all be eating breakfast out of a vending machine

means.


ed: fixed

Addendum (2009-03-28 17:04):
Thanks. (Pim)

To keep up with demand, corners were cut and anti-patterns had become the norm. Anything to keep adding new screens.

Anything... except good coding practices.

Pim:

I wonder what

production will come to awe'll all be eating breakfast out of a vending machine

means.

I'm guessing:

production will come to a halt and we'll all be eating breakfast out of a vending machine

Unfortunately, FIELD42 was overwritten by a hard-coded string and... well you get the picture.

...And thus government was born?

Legacy system grows in size and complexity, losing standardization and common sense along the way. Developers realize they alone have the knowledge to maintain said system and make themselves irreplaceable, accepting the job security and perks that come with entrenching yourself in a system. New developer comes to management with grand ideas without a business case and is shot down.

TRWTF is that Barb is getting married. Really, who would shackle themselves to that miserable excuse for a human being?

And we re-learn a lesson: In the eyes of management, a slick GUI potemkin will always trump whatever steaming pile backs it.

John Whittet:

TRWTF is that Barb is getting married. Really, who would shackle themselves to that miserable excuse for a human being?

You're thinking of Barb in Accounts. Barb in HR is foxy.

Robajob:

John Whittet:

TRWTF is that Barb is getting married. Really, who would shackle themselves to that miserable excuse for a human being?

You're thinking of Barb in Accounts. Barb in HR is foxy.

Wait, which one was caught snogging behind the liquid nitrogen tank?

Sounds like a great job!! Who wants to sit around worrying about this column name and that column name when you have free food! I have to maintain a horrible system equally as bad as that one and I have to bring in my own damn food!

P.S. are you guys hiring?

Politico:

Robajob:

John Whittet:

TRWTF is that Barb is getting married. Really, who would shackle themselves to that miserable excuse for a human being?

You're thinking of Barb in Accounts. Barb in HR is foxy.

Wait, which one was caught snogging behind the liquid nitrogen tank?

That was Barbara, the plant engineer. She hates being called Barb.

...and if we upset that boat, production will come to awe'll all be eating...

OMG WTF!?!?!

I learned this the hard way. We were being asked about charts and graphs and as a joke I created a dashboard that over used Flash charts to the point of being ridiculous.

... I am now support that application and it is forward facing to our company.

Wayne W.:

I learned this the hard way. We were being asked about charts and graphs and as a joke I created a dashboard that over used Flash charts to the point of being ridiculous.

... I am now support that application and it is forward facing to our company.

Like they say: Software development is like sex. One mistake and you support it for life.

Anony-mouse:

Like they say: Software development is like sex. One mistake and you support it for life.

Or for 20 years, anyway.

I like this better:
production will come to awe'll all be making shoes with awls for a living, get it?

Code Dependent:

I like this better:
production will come to awe'll all be making shoes with awls for a living, get it?

That's just awl-ful!

Anyone else chuckle and think about how this story correlates to Wall Street these days? They do horrible things and get rewarded for it. Would they take the initiative to fix things before it's to late, they might loose those rewards, so they keep doing questionable things just so they make out.

It sounds to me like the usual story of the new developer that comes in and wants to start over from scratch because they know better.

It seems like if he just improves the app through small, consistent improvements, refactoring, and developing new code with a standard methodology, eventually, over time, it will turn around and be a much better app without "upsetting the boat"

Everybody say it with me in unison:

"Loose" -- rhymes with goose
"Lose" -- rhymes with news
"Looser" -- what my shoes are when they come untied
"Loser" -- what I am when I can't spell


P.S. I work for PEDANT

Neil:

It sounds to me like the usual story of the new developer that comes in and wants to start over from scratch because they know better.

It seems like if he just improves the app through small, consistent improvements, refactoring, and developing new code with a standard methodology, eventually, over time, it will turn around and be a much better app without "upsetting the boat"

From the article:

He proposed revamping the applications to store all UI information dynamically, recreate the table layout to have meaningful column names, and if nothing else, take the time to review source code headings to make sure that it matched the source file's intended purpose.

I don't think he was proposing that they scrap the app and start over. He laid out a three-part plan to improve the existing system. Although his plan covered a lot, it could be done (nay, should be done) in a phased approach.

To be honest, it seems more like the usual story of the older developers who are resistant to change.

PEDANT seems like it could use to be a bit more pedantic.

How's that for a five dolar word?

He laid out a 3-part "app revamp" and database redesign plan to improve the system on his first day after working on his first task.

Seems a bit presumptuous to me, rather than being stuck with older devs who won't change their ways, as the article would like you to believe.

bum:

...and if we upset that boat, production will come to awe'll all be eating...

OMG WTF!?!?!

I think it was supposed to be:

...and if we upset that boat, production will come to a halt and we'll all be mixing our metaphors...

This steaming pile seemed to work pretty well, though. Some developers never learn the lesson that if it ain't broke, don't fix it.

Anony-mouse:

Wayne W.:

I learned this the hard way. We were being asked about charts and graphs and as a joke I created a dashboard that over used Flash charts to the point of being ridiculous.

... I am now support that application and it is forward facing to our company.

Like they say: Software development is like sex. One mistake and you support it for life.

Plus they're both wicked fun and involve the messy transfer of fluids.

Neil:

He laid out a 3-part "app revamp" and database redesign plan to improve the system on his first day after working on his first task.

Seems a bit presumptuous to me, rather than being stuck with older devs who won't change their ways, as the article would like you to believe.

Maybe the article is slanted. But, his ideas should be judged on their technical merit, not on how they affect the reputation of the team and the availability of catered breakfasts.

In my experience, usually the fresh face IS the one who knows what's what because they haven't had to support legacy shit for years and become complacent.

You wouldn't believe the number of times I've been like this guy, and brought ideas to fix what kind of sort of works by chugging along, and get it shot down because the more 'senior' guys think they know better. They might, but their vision is clouded by having to see and work with garbage code. It poisons their mind and taints their ability to do what's right.

John Whittet:

TRWTF is that Barb is getting married. Really, who would shackle themselves to that miserable excuse for a human being?

UPDATE tbl_newsfeed0010aa12
SET FIELD32 = 'Barb is a miserable excuse for a human being'
GO

Wait-- was "private gossip only seen in IT department feeds" FIELD32 or FIELD23?

While what you say might be true, it is of course partly your fault.


There's an old saying you'd do well to learn - "Nobody likes a smartass".

You may have all the technical ability in the world, but if (as is so often the case) you are completely lacking in diplomatic/interpersonal skills, you're going to find all your great ideas being shot down. As long as the other people you are working with are humans, you need to realise this is *your* problem and *you* need to work to solve it; seething with impotent rage that other humans keep behaving like, well, humans isn't going to get you very far.

Frequent Flyer:

While what you say might be true, it is of course partly your fault.


There's an old saying you'd do well to learn - "Nobody likes a smartass".

You may have all the technical ability in the world, but if (as is so often the case) you are completely lacking in diplomatic/interpersonal skills, you're going to find all your great ideas being shot down. As long as the other people you are working with are humans, you need to realise this is *your* problem and *you* need to work to solve it; seething with impotent rage that other humans keep behaving like, well, humans isn't going to get you very far.

This was, of course, a reply to ObiWayneKenobi!

That's so sad, but extremely normal in most IT organizations.

my name is missing:

That's so sad, but extremely normal in most IT organizations.

You haven't seen normal till you've seen EXTREMELY NORMAL!! It's so normal, it's EXTREME, man!

And where does one find this "Advisor-Type" person? I could use one about now. I mean, it's great to code and actually see what I write help someone, but I keep getting this sinking feeling that no one is actually looking at what I'm coding.

JamesQMurphy:

Neil:

He laid out a 3-part "app revamp" and database redesign plan to improve the system on his first day after working on his first task.

Seems a bit presumptuous to me, rather than being stuck with older devs who won't change their ways, as the article would like you to believe.

Maybe the article is slanted. But, his ideas should be judged on their technical merit, not on how they affect the reputation of the team and the availability of catered breakfasts.

HeHeHe.
I'll bet you want to be a fireman when you grow up.

This is a nice companion article to yesterday's article. In both, we have a "simple fix" that is actually complicated.

Also, what program is that in the image for this article? The one on the right monitor looks like it might be Norton Commander.

Neil:

It sounds to me like the usual story of the new developer that comes in and wants to start over from scratch because they know better.

It seems like if he just improves the app through small, consistent improvements, refactoring, and developing new code with a standard methodology, eventually, over time, it will turn around and be a much better app without "upsetting the boat"

That's my take on this whole situation. Clearly he doesn't have buy-in to rebuild the entire system. However, he does have authority over his own assigned parts of the system. It's a lot easier to refactor a single code module that you're in the middle of enhancing. Just don't take too long or they'll question why a simple code change is taking so long.

The problem however lies in the scope of his improvements. Sometimes you can only improve the code, othertimes you KNOW it has to go hand in hand with renaming the fields in the underlying tables. Improve just the code and you still have the same crap in the background.

Oh well. At the very least he can fix and update all the comments.

Dmitriy:

This is a nice companion article to yesterday's article. In both, we have a "simple fix" that is actually complicated.

There's nothing worse than having someone think that a simple change request should be quick and easy to do. When in reality it's very time consuming and complicated.

Being on the shit-end of that situation so many times has taught me something. When you're not the one implementing the change, and don't understand how it's done, then don't presume that your minor request is actually going to be easy and quick to make. Ask the person for a time/cost estimate. Don't tell them "What? It's a tiny change...". Those people are douchebags.

Hah! Is funny because first letters of company name spell "pedant"!

I have a suspicion that the story is a little overstated...

- Young, new guy comes in, sees screwy system, suggests improvement.
- Older guys resist dramatic change, because giving higher-ups a whiff that everything isn't rainbows and unicorn farts might hurt their rep, lead to less perks.

So, chances are they probably would agree to changing things gradually over time if they can do so without bucking the system too much.

Not much of a WTF there... just fix it over time without taking the system down in the process.

Jon E.:

And we re-learn a lesson: In the eyes of management, a slick GUI potemkin will always trump whatever steaming pile backs it.

No, in the eyes of ANYONE except programmers, a slick GUI is what matters, because it's what's visible. An application can have the best code structure, the fastest algorithms, whatever, but if the front end is horrible people aren't going to like it.

anonymouse:

JamesQMurphy:

Maybe the article is slanted. But, his ideas should be judged on their technical merit, not on how they affect the reputation of the team and the availability of catered breakfasts.

HeHeHe.
I'll bet you want to be a fireman when you grow up.

No wonder the world is so fucked up.

Arguably, that's why a lot of applications that programmers like don't do well in the wider market. It doesn't matter that our favorite apps are technically superior, because their UI is such that it puts off everyone who isn't dedicated to really learning the application. I see this especially with editors and design tools.

Jamie:

Anony-mouse:

Wayne W.:

I learned this the hard way. We were being asked about charts and graphs and as a joke I created a dashboard that over used Flash charts to the point of being ridiculous.

... I am now support that application and it is forward facing to our company.

Like they say: Software development is like sex. One mistake and you support it for life.

Plus they're both wicked fun and involve the messy transfer of fluids.

... messy transfer of fluids ...

Well, for programming, maybe in YOUR case, but for me, I type my code. With my hands.

Steven's proposal is the real WTF. A young developer who just came on board, proposing a broad redesign of a system that works despite what he thinks of his aesthetics? Come on, what did he think the senior devs would say? I wouldn't be surprised if he made up the whole bit about job security to make himself look better.

Welcome to the industry, kid. You're working for the end-user, not for yourself.

When many naive writers first wander their way from the classroom into the working world, invariably they will produce some lousy WTF articles. Usually though, there is an advisor-type person who will review the article, point out "you're doing it wrong", and turn the failure into a learning experience.

[The premise of the article wasn't bad, if "copy and pasted" from previous articles, but the writing lacked "punch."]

I've worked in places like this. The elite team are lionized heroes, fighting the technical fires that break out not infrequently in the critical systems. They are admired, praised, rewarded. Slack is cut for them--we don't stop for red lights, we have our sirens and flashers going!

Of course, any crisis which is prevented is a lost opportunity for glory. So, in theory, the best qualified to prevent fires--the "fire fighters"--have the least incentive to actually prevent fires, as long as they can just knock the fires quickly and cheaply (and heroically) down.

Many organizations are captive to their heroes. It's sad, but it works.

m0ffx:

Jon E.:

And we re-learn a lesson: In the eyes of management, a slick GUI potemkin will always trump whatever steaming pile backs it.

No, in the eyes of ANYONE except programmers, a slick GUI is what matters, because it's what's visible. An application can have the best code structure, the fastest algorithms, whatever, but if the front end is horrible people aren't going to like it.

Sad but true. And yet another reason for people to use OS X instead of XP instead of Linux/BSD.

Note: I'm a BSD user, if you were about to brand me as a linux zealot or a mac fanboy, shove off :P

Well kid we can put changes on hold for several months, re-write that system, risk breaking who knows what and spend several thousand hours of developer time to bring it up to your high standards. Or someone could spend 3 or 4 hours doing copy paste programming and have it working by tomorrow. Let me think about it.

captcha: penis

Neil:

It seems like if he just improves the app through small, consistent improvements, refactoring, and developing new code with a standard methodology, eventually, over time, it will turn around and be a much better app without "upsetting the boat"

I don't know where you have been working, while sounding good in theory, what you describe fails to work in reality. Very, very seldom can design changes at the exterior (i.e. small chunks of code at a time) improve a crappy architectural design. Until you can hit those core pieces (which likely involves major changes) the system is going to remain a piece of crap. Sure, there may now be pieces that are decently designed and coded, but they will still have a *hacky* smell to them because they had to be bastardized to fit in with the lousy architecture.

The best route for any *newbie* is to first learn how and why the existing team does what it does. Bide your time doing a good job and earning your respect. Maybe work on your ideas in your spare time. Then after becoming part of the team, your chances of initiating more sweeping changes rises dramatically. Especially if you have working prototypes to demonstrate. If you come in shooting, you will be shot down even if your ideas are good.

I don't really see a WTF here. This is common business practice. Not good common business practice, but common.

Dolorous.