Hacker News Reader

Comment by forinti | Hacker News Reader

I once worked for a bank will now tell this story from the IT department's point of view.

A manager did not want to give the IT department the resources they needed to develop this new app, so he got a coder to hack together a solution which is probably unmaintainable and which they will eventually inherit anyway. The fact that you mentioned VB makes the story even funnier to me, because my department was frequently the victim of a code-and-run accountant who wrote awful Access apps (it's the worst code and data modeling I ever saw). Inevitably, the day comes when these apps have to be integrated with the rest of the infrastructure or the original coder doesn't want to deal with his mess.

View on HN

You missed the part where the users preferred the OP's apps.

An IT department exists to satisfy the company's needs, not vice versa. If you can't do the job with the 'resources' given to you, resignation is always an option. But don't fail to do your job and then whine about 'resources'.

Actually, you could argue that the bank had the resources. It's just that one manager didn't want to share his with other people.

People liked and used these apps a lot at my bank too. And that's what made the problem worse. The apps didn't scale, the data was inconsistent or simply not structured (so it was hard to pump it into the main database) and the code was terrible, so it was very hard to add new features.

These things work well for a while (not much data, few users), but when the going gets tough, IT pays the price.

In my experience the users prefer the apps right up until they stop working. Maybe the developer leaves, maybe the mainstream development organization changes some other system it relies on, maybe the auditors show up and the security guys lock down the firewalls and stuff running on a PC under someone's desk no longer has access. Hell, maybe that PC's hardware fails for some reason, maybe someone makes a mistake and said developer didn't use the central, backed-up version control.

Then the users come to IS and piss and whine but get nothing but blank stares in return. And you know, stuff IS does takes time, because we build it to be supportable for the next decade or two (yes really). We write a runbook so someone who's never seen it before can recover it if it fails at 3am, and we make sure it's monitored. We get it signed off by compliance for regulatory oversight. We penetration test it. We back it up offsite and replicate it to the DR site. We stick a generator behind it and we know how many Watts of power it needs (we even know what it weighs so we don't overload the floor in the datacentre). We take its dependencies into account when doing any other work.

Basically, we act like grown-ups with other people's money, something they've largely forgotten in the front office.

Believe me, VB was not my choice. :)

My boss was the kind of guy who wrote the kind of code you are talking about. In fact, he would tell me to not waste time making the code "pretty," just get things done quickly. I simply ignored him, and wrote clean, well designed code anyway. :)

I always write in the most productive language I can, given the choice. But it is still possible to design and structure your code well in even the worst languages.

I understand the concerns IT has about "cowboy coders." But we're talking about people who didn't even understand the relative precedence of addition and multiplication, in this case. So this was more than just wanting to by pass bureaucracy, I'm honestly not sure whether they were capable of implementing the mathematical models my boss wanted. (Not that I was a math genius, but I had mostly mastered operator precedence.)

Reply on news.ycombinator.com