Comment On Batch of Trouble

Ben had already been with the University for a few years when Dave joined the team. At some point during the interview process, Dave reached the conclusion that he was here to modernize the team. As a result, he started on a Tuesday, and by Wednesday was telling everyone how he would do their job. [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Batch of Trouble

2012-06-06 08:04 • by ParkinT
A whole chapter of begats was required to trace the roots of the system.


I like this! A tinge of very familiar pain struck me as I read it.

Re: Batch of Trouble

2012-06-06 09:07 • by KattMan
382602 in reply to 382601
I prefer bagets to begats.
They don't leave such a bad aftertaste and cost less.

Re: Batch of Trouble

2012-06-06 09:07 • by bob (unregistered)
almost frist

Re: Batch of Trouble

2012-06-06 09:08 • by KattMan
382604 in reply to 382602
I do have to wonder though, did no one have to validate the new system beyond his demo of it?

Re: Batch of Trouble

2012-06-06 09:10 • by serguey123
382605 in reply to 382604
Hahahhaah, good joke Kattman!

Re: Batch of Trouble

2012-06-06 09:17 • by beorn (unregistered)
so why did they let him change a working well documented system?

Re: Batch of Trouble

2012-06-06 09:18 • by KattMan
382607 in reply to 382605
serguey123:
Hahahhaah, good joke Kattman!

Not sure which one you consider the joke around here, the begats or the validation.

:)

Re: Batch of Trouble

2012-06-06 09:20 • by Not Nagesh (unregistered)
Really? Management (which actually does have a purpose) let this guy run amok for two years without any evaluation of what he was doing? Typical University IT team perhaps. I never worked on one, but have only heard stories. In the end, maybe everyone got what they deserved.

Re: Batch of Trouble

2012-06-06 09:29 • by hymie
It seems that things weren't going so well at Dave's new job. A month later he called, hoping that they might need a little more consulting help. "I've got a lot of free time, now," he said.

*snif* I love a happy ending.

Re: Batch of Trouble

2012-06-06 09:44 • by Finagle (unregistered)
382610 in reply to 382606
beorn:
so why did they let him change a working well documented system?

Murphy's Laws of Computer programming, Rule #9: "If a program is useful, it will have to be changed."

Re: Batch of Trouble

2012-06-06 09:52 • by PiisAWheeL
382611 in reply to 382606
beorn:
so why did they let him change a working well documented system?
That wasn't their goal. It seems like they just hired him on and let him do whatever he wanted with little to no accountability. But it went unnoticed because he was such an annoying prick that everyone figured if he wasn't bothering them they could get some work done.

Re: Batch of Trouble

2012-06-06 10:02 • by Mike D. (unregistered)
382612 in reply to 382604
KattMan:
I do have to wonder though, did no one have to validate the new system beyond his demo of it?

Everyone else was doing Real Work (TM) and had no time for that. However, this overhaul is what Dave was hired to do, and they would be throwing away two years of paying him if they didn't deploy it, so ...

Re: Batch of Trouble

2012-06-06 10:10 • by Mike (unregistered)
382613 in reply to 382612
Actually, the article never said that is what he was hired to do. He just took it upon himself to do the rewrite because he thought he could apply a little "I can do it better".

Re: Batch of Trouble

2012-06-06 10:18 • by Code Slave
You know, I'm honestly surprised that Dave didn't just turn off the old batch files. I really expected him to delete them, and then search out any backups and delete them as well, and rifle through all the previous begatters offices to purge any possible paper copies.

Re: Batch of Trouble

2012-06-06 10:24 • by ur (unregistered)
382616 in reply to 382612
Mike D.:
KattMan:
I do have to wonder though, did no one have to validate the new system beyond his demo of it?

Everyone else was doing Real Work (TM) and had no time for that. However, this overhaul is what Dave was hired to do, and they would be throwing away two years of paying him if they didn't deploy it, so ...

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Re: Batch of Trouble

2012-06-06 10:35 • by Stev (unregistered)
382617 in reply to 382606
beorn:
so why did they let him change a working well documented system?


If it ain't broke, fix it until it is.

Seriously though, I do hate the whole notion of "if it ain't broke, don't fix it". There's some truth to it, but frankly if we all took that approach, we'd never invent anything - including the computer. We used candles for hundreds of years, they were simple and they "just worked". Sure, they occasionally set things on fire but so does the modern lightbulb (well, possibly not the energy saving ones).

The point is, if there's a better way to do something then you should probably do it, but that also means you should do the doing part better as well. Get a list of bullet points of the proposed and the old system, deciding what the pros and cons are. Does the old system have a lot of cons? Then an upgrade is due. Does the new system have a lot of cons? Then scrap it and try again.

These kind of antics hold everyone back. A good, solid design with a good testing process would have made the new system 10x better than the old system but instead, 10 years down the line when Batch scripts suddenly no longer work (Change of OS? NEW OS? Overzealous security software?) they'll be stuck on either outdated systems or scrambling to get something half as good up ASAP.

Planning. Do it.

Re: Batch of Trouble

2012-06-06 10:36 • by Scrummy (unregistered)
This is why you don't let a person or team just go into a hole and write a bunch of code for several months. I can't stress enough how Agile development would have mitigated this process. When you work in small sprints, it guarantees that you will get a complete product that works, with documentation.

Re: Batch of Trouble

2012-06-06 10:43 • by verisimilidude (unregistered)
382619 in reply to 382616
ur:

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.

Re: Batch of Trouble

2012-06-06 10:44 • by KattMan
382620 in reply to 382617
Stev:
beorn:
so why did they let him change a working well documented system?


If it ain't broke, fix it until it is.

Seriously though, I do hate the whole notion of "if it ain't broke, don't fix it". There's some truth to it, but frankly if we all took that approach, we'd never invent anything - including the computer. We used candles for hundreds of years, they were simple and they "just worked". Sure, they occasionally set things on fire but so does the modern lightbulb (well, possibly not the energy saving ones).

The point is, if there's a better way to do something then you should probably do it, but that also means you should do the doing part better as well. Get a list of bullet points of the proposed and the old system, deciding what the pros and cons are. Does the old system have a lot of cons? Then an upgrade is due. Does the new system have a lot of cons? Then scrap it and try again.

These kind of antics hold everyone back. A good, solid design with a good testing process would have made the new system 10x better than the old system but instead, 10 years down the line when Batch scripts suddenly no longer work (Change of OS? NEW OS? Overzealous security software?) they'll be stuck on either outdated systems or scrambling to get something half as good up ASAP.

Planning. Do it.


You're new here aren't you?

Re: Batch of Trouble

2012-06-06 10:56 • by Ken B. (unregistered)
382621 in reply to 382616
ur:
Mike D.:
KattMan:
I do have to wonder though, did no one have to validate the new system beyond his demo of it?
Everyone else was doing Real Work (TM) and had no time for that. However, this overhaul is what Dave was hired to do, and they would be throwing away two years of paying him if they didn't deploy it, so ...
Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?
There's a difference between "batch files" and ".bat files".

Re: Batch of Trouble

2012-06-06 11:03 • by KattMan
382622 in reply to 382621
Ken B.:
There's a difference between "batch files" and ".bat files".


Reality and commen knowledge (let's not call it sense because that isn't common) are not the same. More often than not, I have heard Dos Bat files simply called batch files and in this context I would tend to relate them the same, if only to add to the WTFery.

Re: Batch of Trouble

2012-06-06 11:03 • by Steve The Cynic
382623 in reply to 382617
Stev:
We used candles for hundreds of years, they were simple and they "just worked". Sure, they occasionally set things on fire but so does the modern lightbulb (well, possibly not the energy saving ones).

Read your history a bit more carefully. Candles had far less "just worked" about them than you think. Compared to even a feeble 40W "candle" bulb, they are dim and produce a murky yellow-orange light. They mark the ceiling with a smoky residue, and that's the best of them. Tallow candles are even dimmer, produce more smoke, and must be trimmed regularly or they will go out. And candles set things on fire a *lot*.

By comparison, electric light bulbs are almost zero-maintenance, very much brighter, don't flicker or blow out in windy conditions, are smoke-free, and cause fires only rarely.

Re: Batch of Trouble

2012-06-06 11:04 • by nB (unregistered)
382624 in reply to 382617
Stev:


If it ain't broke, fix it until it is.

Seriously though, I do hate the whole notion of "if it ain't broke, don't fix it". ...We used candles ...

The point is, if there's a better way to do something then you should probably do it,
The adage doesn't apply to a new widget. It applies to a single instance of a widget.
I have a machine. It runs fine and it ain't broke, thus I should not attempt to fix it. As to the Candles, developing a working lightbulb by candlelight so that you no longer need candles is perfectly fine. If your bulb doesn't work you still have candles. This particular DWTF is actually fairly close to that since they still had the old system.
-nB

Re: Batch of Trouble

2012-06-06 11:05 • by nB (unregistered)
382625 in reply to 382619
verisimilidude:
ur:

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.
LISP inline'd in c++?

Re: Batch of Trouble

2012-06-06 11:09 • by snoofle
382626 in reply to 382619
verisimilidude:

Depends on the language you use. Perl ... Python ... Java .. Visual Basic 6
Not necessarily. Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program. Anything, including all of the above, and everything else, can be used to write an incomprehensible undocumented steaming pile of unmaintainable wtf.

It's the carpenter; not the hammer that makes the difference.

Re: Batch of Trouble

2012-06-06 11:10 • by airdrik
382627 in reply to 382619
verisimilidude:
ur:

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.

But if you use java, that means that you're going to be using xml and xml (especially java with xml) means enterprizy, and we all know that you should go for the enterprizy systems over the non-enterprizy systems, so he must have been using java and xml.

Re: Batch of Trouble

2012-06-06 11:11 • by pjt33
382628 in reply to 382619
verisimilidude:
ur:

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.

According to the article (I know, I know), it was "a BPM tool".

Re: Batch of Trouble

2012-06-06 11:11 • by Smug Unix User (unregistered)
Give me a good batch file any day.

Re: Batch of Trouble

2012-06-06 11:12 • by KattMan
382630 in reply to 382619
verisimilidude:
ur:

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.


So you threw VB in there just because WHY?
VB showed problems with programmers so much easier because "everyone" could pick it up. It had error handling just like any othe rlanguage, but since "everyone" could program in it they never used it. Problem wasn't the language, but the programmers, VB just made it easier to spot the problems later because it was more easily read.

Just don't get me started on those "hey I can read this I must be a programmer" types. There are far to many of them still banging on a keyboard thinking they are writting good code.

Re: Batch of Trouble

2012-06-06 11:26 • by mott555
382631 in reply to 382626
snoofle:
verisimilidude:

Depends on the language you use. Perl ... Python ... Java .. Visual Basic 6
Not necessarily. Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program. Anything, including all of the above, and everything else, can be used to write an incomprehensible undocumented steaming pile of unmaintainable wtf.

It's the carpenter; not the hammer that makes the difference.


Only somewhat true. Some hammers (like Objective-C) have a striking surface made of low-density polystyrene foam, only one claw, and there's a wasp nest attached to the handle. It actually works better if you hold it upside down and use the wasp nest as the striking surface, but that's against the manufacturer's terms of use and they won't let you sell any products made with a hammer used in such a fashion. Unfortunately the company that makes these hammers has an awesome marketing team, meaning a lot of us carpenters get forced to use it because the client says so. And then they wonder why it takes so long to build something.

Re: Batch of Trouble

2012-06-06 11:38 • by Nagesh (unregistered)
382632 in reply to 382630
KattMan:
verisimilidude:
ur:

Yeah, two years - how can it take that long to re-implement something that was even feasible with batch files?

Depends on the language you use. Perl - real quick but maintenance will be tough. Python - Not as quick but maintainable. Java - Not quick and if not done well totally unmaintainable. Visual Basic 6 - Well, maybe that's what he used. It would explain the two years, lack of error handling, and inability for anyone else to pick up the system.


So you threw VB in there just because WHY?
VB showed problems with programmers so much easier because "everyone" could pick it up. It had error handling just like any othe rlanguage, but since "everyone" could program in it they never used it. Problem wasn't the language, but the programmers, VB just made it easier to spot the problems later because it was more easily read.

Just don't get me started on those "hey I can read this I must be a programmer" types. There are far to many of them still banging on a keyboard thinking they are writting good code.


Also, Java ain't being as bad as some scarecrow is saying. Very often I am geting code, however, that needs me massage it to be clean and catching all exception.

Re: Batch of Trouble

2012-06-06 11:39 • by campkev
the lower the chance of Dave having an "unfortunate" accident

I think you put the quotes around the "wrong" word

Re: Batch of Trouble

2012-06-06 11:42 • by beorn (unregistered)
382634 in reply to 382633
campkev:
the lower the chance of Dave having an "unfortunate" accident

I think you put the quotes around the "wrong" word


It's not actually wrong?

Re: Batch of Trouble

2012-06-06 11:46 • by ¯\(°_o)/¯ I DUNNO LOL (unregistered)
So what's a BPM tool, anyhow?

Bowel-like Program Movement?

Re: Batch of Trouble

2012-06-06 11:50 • by Matt (unregistered)
TRWTF is management not correcting what was obviously a bad hire. It happens - substandard people get hired. The wrong way to deal with it is let them sit in the corner and hope they don't cause too much damage. Only two options: Fix 'em or Fire 'em.

Re: Batch of Trouble

2012-06-06 11:58 • by Nagesh
#3. Documentation is obvious lie.

Has anybody here work on complete documented system? I bet Rs 500/- from my next salary slip.

Re: Batch of Trouble

2012-06-06 12:05 • by neminem (unregistered)
382640 in reply to 382626
snoofle:
Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program.


I agree completely about Perl - while it doesn't necessarily make it as easy to write -large- maintainable applications as some languages, I've certainly seen decent-sized scripts in perl that were entirely pretty and easy to figure out. Perl kinda gets a bad rap just because it makes it so easy to write unreadable garbage if that's what you're trying for. That said...
http://en.wikipedia.org/wiki/Whitespace_%28programming_language%29
http://en.wikipedia.org/wiki/Brainfuck
http://en.wikipedia.org/wiki/INTERCAL_programming_language

Technically Turing Complete! (Yes, I do know you were actually implying that only about languages that were designed to get work done in them, rather than languages designed intentionally as parodies, but I like nitpicking.)

Re: Batch of Trouble

2012-06-06 12:11 • by Kensey
382641 in reply to 382618
Scrummy:
This is why you don't let a person or team just go into a hole and write a bunch of code for several months. I can't stress enough how Agile development would have mitigated this process. When you work in small sprints, it guarantees that you will get a complete product that works, with documentation.


Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

(The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.)

Re: Batch of Trouble

2012-06-06 12:15 • by Scrummy (unregistered)
382642 in reply to 382641
Kensey:

Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

(The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.)


In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.

Re: Batch of Trouble

2012-06-06 12:16 • by russ0519
382643 in reply to 382631
mott555:
snoofle:
verisimilidude:

Depends on the language you use. Perl ... Python ... Java .. Visual Basic 6
Not necessarily. Anything, including Perl, can be used to write a clear, comprehensible, well documented and maintainable program. Anything, including all of the above, and everything else, can be used to write an incomprehensible undocumented steaming pile of unmaintainable wtf.

It's the carpenter; not the hammer that makes the difference.


Only somewhat true. Some hammers (like Objective-C) have a striking surface made of low-density polystyrene foam, only one claw, and there's a wasp nest attached to the handle. It actually works better if you hold it upside down and use the wasp nest as the striking surface, but that's against the manufacturer's terms of use and they won't let you sell any products made with a hammer used in such a fashion. Unfortunately the company that makes these hammers has an awesome marketing team, meaning a lot of us carpenters get forced to use it because the client says so. And then they wonder why it takes so long to build something.



You're talking about XCode aren't you?

Re: Batch of Trouble

2012-06-06 12:24 • by myName (unregistered)
"It wasn't a terribly pretty system, but it did have a few very important features: It worked."

Sometimes a piece of code will be defended in the comments with this phrase and the poster will be decried, yet it passes unmentioned this time.

Re: Batch of Trouble

2012-06-06 12:36 • by Jeff (unregistered)
382645 in reply to 382617
Stev:
Planning. Do it.
I plan to.

Re: Batch of Trouble

2012-06-06 12:46 • by Nagesh
382646 in reply to 382642
Scrummy:
Kensey:

Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

(The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.)


In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


I endorse this view in full & total.

Re: Batch of Trouble

2012-06-06 12:52 • by Michael (unregistered)
Having worked at a university in the past, this story is entirely credible. You have to understand how a university is different from a Real Job:

* The university's money doesn't mostly come from satisfied customers. It comes from vague threats of violence against reluctant taxpayers. So there is no need to show a profit, or a return on investment.

* Given the lack of motivation to spend the minimum amount of money as productively as possible, managers' self esteem is directly tied to how much money they spend not how much they make for their employer.

* This means if you have an opportunity to hire someone you do so, in order to build your empire and keep those salary dollars flowing through your hands in future years. It is not important that the employee produce good work inexpensively, since profits and productivity don't matter.

* By the same rule, you'd never want to fire anyone because that takes you down the ladder a notch. Besides, you can't fire a government employee for anything less than mass chainsaw murder fully recorded by the security cameras. Or hate speech, i.e. saying anything not Politically Correct.

Under this system (non-capitalism) it is amazing anything works at all.

But of course capitalism is TRWTF. So what are we to do?

Re: Batch of Trouble

2012-06-06 13:00 • by Remy Porter
382648 in reply to 382642
That's a really lousy thing to say, though.

"Agile didn't work!"
"Then you did it wrong!"

That said- Agile is a good way to get a team in sync. It's not a project management technique, it's not even a "coding fad"- it's how you organize a team and keep them headed in the same direction.

Re: Batch of Trouble

2012-06-06 13:02 • by Paul Neumann (unregistered)
382649 in reply to 382622
KattMan:
Ken B.:
There's a difference between "batch files" and ".bat files".


Reality and commen knowledge (let's not call it sense because that isn't common) are not the same. More often than not, I have heard Dos Bat files simply called batch files and in this context I would tend to relate them the same, if only to add to the WTFery.
Thanks for pointing that out.

Re: Batch of Trouble

2012-06-06 13:04 • by Paul Neumann (unregistered)
382650 in reply to 382623
Steve The Cynic:
<yawn>...
By comparison, electric light bulbs are almost zero-maintenance, very much brighter, don't flicker or blow out in windy conditions, are smoke-free, and cause fires only rarely.
Learn abstraction. The comparison being made is that lights ARE more better(TM), but prior to the invention candles were "not broke."

Re: Batch of Trouble

2012-06-06 13:14 • by Mario (unregistered)
382651 in reply to 382645
I just laughed out loud in my cube

Re: Batch of Trouble

2012-06-06 13:24 • by KattMan
382652 in reply to 382651
Mario:
I just laughed out loud in my cube

At least you have a cube.

Re: Batch of Trouble

2012-06-06 13:24 • by Nagesh (unregistered)
382653 in reply to 382646
Nagesh:
Scrummy:
Kensey:

Sure, that sounds good in theory, but I worked with an actual Agile dev team. They turned out plenty of awful code and had a project basically thrown away by the client after months of work because oops, they forgot to gather requirements first! So when they triumphantly unveiled the first demo (that the client knew nothing about), the reaction was "...yeah, this doesn't really work for us, and by the way how much of our money did you spend on this?"

By contrast some of the very best code I've seen was turned out by single programmers working alone "off in a cave", with a coherent vision and the skills to realize it.

(The dirty little secret of all the coding fads like Agile and XP is this: no technique on earth can make bad programmers into good programmers. Only becoming a good programmer can. And if your team is made of good programmers, it doesn't much matter which technique(s) they use, as long as they're all in sync together.)


In my experience, when an Agile development effort fails, it's because the team wasn't doing Agile correctly.


I endorse this view in full & total.

I also be learning about True Scotsman Fallacy this weekend.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment