On contexts, rules, flexibility and purity

[jZed]

dragonchild and I got into a bit of a tussle over here and we finally arrived at the crux of the matter.

dragonchild, in private message to me, said this about web administration of databases (e.g. a CGI script to backup and restore a db):

I guess my point really is "Either it's a toy, in which case whatever, or it's not, in which case procedures are needed. That includes no web administration, period." If your company depends on this, then treat it like your company depends on it

I find that really admirable (no sarcasm) and I'm glad there are people like you who take data administration seriously. Let me give an example of why, although I admire it, I still can't accept it as a rule written in stone. I work mostly for not-for-profit organizations that use databases to provide information to communities in need. Sometimes I have the luxury of starting the organization from scratch but more often then not, I walk into an IT nightmare caused by years of not having the funds or knowledge to do the right IT thing. I have a client now whose ISP told them they had ssh privs but never actually activated a login account and who has not responded to requests in over a month. Get a new ISP says I. Next funding cycle says they. Meanwhile, the community that depends on information from the organization is going without. So ... do I let the community do without, quit and move on to a job with a reasonable IT setup, or do I hack something together with FTP and web administration to keep the thing working for a couple of months until we transition to the new ISP?

There are more contexts than just "toy" and "real business". The rules that apply in the different contexts are different. In some contexts, flexibility trumps purity of design.

[dragonchild]

This is why I am so adamant about doing things properly. It is only when you know how to do things properly that you understand which rules are fine to break in which circumstances and, most importantly, what the potential consequences are and what risks those entail. In other words, you only know when to break the rules after you know the rules.

If someone demonstrates ignorance of the rules, I'm going to clue-by-four them with said rules. This is what I did in the referenced thread and I think I was correct in doing so. The OP hadn't demonstrated why the standard processes were insufficient for his needs. So, start from first principles.

I break the rules all the time. But, I know what can happen if I do and I have determined that the risks are worth it. There are many people who are better coders or DBAs or sysadmins than I am. But, being an effective team lead or a DBA or a sysadmin is much more than pure skill.

As for contexts - it's about risk management. If your business would completely collapse if a given machine dies, then you need to address that. The proper solution may be "Let's hope it doesn't." because the cost of securing that machine may be more than the cost of restarting the business. If it's not, then the proper solution is to secure the machine. This isn't about purity or anything. It's about business - risk analysis and proper mitigation. Nothing more.

[samizdat]

While I also wishful-thinking-wise agree with everything said on dragonchild's side, I have to cite the Bigger Picture, agreeing with jZed, and say that giving the Users their data takes precedence, whatever kludge it takes. We must always remember that our job is to serve the larger community. Our programming/database admin/chipbuilding/whatever does not exist within a vaccuum, and the world will remember Al Gore's movie long after the database server his website comes from is returned to silica dust.

[gloryhack]

++E3

I don't know the full situation that prompted the short flurry of nodes, but if the organization in question is a charitable one with real lives at stake, screw the business needs and help the people one way or another. I, personally, could not look a child in the face and say, "Well, kid, ya know, I think it'd be nice if you could sleep in a bed under a roof tonight, but the database server is down right now and our internet service provider is unresponsive. Here's a newspaper you can cover up in when it gets cold".

I will now spare the reader my rant about short sighted executives moving on to equally green pastures after their blunders have cost a great number of working men and women their homes.

[perrin]

Hacking around people problems is usually a bad sign. Call the ISP. Tell them you expect to get the service you have been paying them for.

[jZed]

Repeated and continual calls and email have produced no response in over a month. These guys are truly out to lunch. Believe me, my first response was to try to get what we'd paid for and it didn't work. I am not advocating hacks as a regular approach, rather saying that sometimes Real Life isn't flexible, so our response to it has to be.

[andye]

One way to 'hack' this particular RL situation, that I've found effective in the past, is a formal letter (not just an email) to the CEO of the company, copied to the CEO of the parent company (if there is one), or the chairman of the board or whoever, setting out very clearly how they are in breach of contract and what you intend to do about it if they don't pull their socks up. Also when you intend to do it.

An approach like this one has worked very well for me in the past on a Large And Well Known Hosting Company, and just this morning has caused an email vendor to find an USD 1000.00 payment from us that they had actually lost (I was shocked...).

Best wishes, andye

[rodion]

I'm with dragonchild. Don't loose the distinction between toys and serious database maintenance. Toys can be very useful, to learn on, to do serious things you can afford to lose, or to demo something. Sometimes one's whole business can be supporting toy software for people who really need better. That's ok. It can be a good thing to do, but your clients need to know that what they are relying on is a toy that wasn't designed for what they are doing, so when the next funding cycle comes up they can make an informed decision on where to spend their scarce resources -- on a database setup that they can rely on, or on the good works that are the not-for-profit's primary mission. The important thing is that they know what they have signed on for, and the only way to get the point across non-technically is to call it a toy, or something equivalent but more polite. If you don't give them a name to tag the vulnerability with, they will forget about it and blame you when something fails. (OK, they may blame you anyway, but at least you tried.) Anyway, that's my two cents. We each serve where we can best do some good, if we're lucky.

[Robertn]

My guess is you didn’t know quite how bad the situation was when you took the job, but leaving because resources are not available to do the best job possible, certainly won’t improve things either, for a group that probably really needs your help.

It often seems to me, our job is usually to do the best we can with the resources at hand, and if the desired result requires more resources, than management needs to provide the resources or live with diminished expectations (although they usually don’t). I don’t think I’ve never had a job where we’ve always had all the resources we needed, always a fight to get something axed out of the budget.

Without knowing the scope of work to move your site, but knowing that there are a ton of dirt cheap web sites, some even free if you look hard enough, I’d move the site until you can get funding for your preferred provider. That should also give you a good idea of what you’ll need to re-architect.

I’d also stop paying your current provider, they just might give you a call.

[tedv]

I'm mostly with dragonchild on this one. Most systems, especially software, tend towards anarchy over time, and you are the one who has to deal with it. The more you give into "just kludging it", the harder your job becomes in the future. In fact, it sounds like that same attitude on the part of your predecessors is what created this situation in the first place. I wholeheartedly believe your work should bring the system to a greater place of stability (within a reasonable amount of work effort, since you're still trying to maximize profit). It's almost never the case that long term profits are maximized by letting your systems slide into chaos.

That said, I understand there are business situations where kludges might be more desirable then not delivering a product at all. I'm not saying you should never do them. But generally management doesn't understand the difference between a kludge and a good long term solution, except that the latter usually costs more money. If you have to write a kludge, write one that at least pushes the system in the direction of order rather than more chaos.

In other words, what kinds of solutions can you write that either A) bring you closer to the ideal solution or B) are absolutely temporary solutions that will break soon enough that management realizes a more ideal solution is also more cost effective?

[wjw]

I think this is one of those times when you "gotta do what ya gotta do", in that if you have to make the rent based on the results of the project you describe, you should probably make sure your working on other projects as well.

Calling any tool that functions a toy is a bit harsh. The java developers I work with call Perl a "toy", and in relative terms from their point of view, they are right. But ask them to write java code that does what my Perl code does and they suddenly have other things to do.

I have used web admin tools in commercial situations and have had good results. Tools like that buy you the time to do things right(or at least better). Getting things "right" is an iterative process, and unending because needs are dynamic. I would say, get 'em up and running if you care enough to do so, with whatever tools get them there quickly and without doing damage to your chances of making things better later.

Principles are great if you can afford them...

[xiaoyafeng]

JZed ++
It's not a tech issue,so you needn't settle it out with tech.Hack is a way but is a last way.You should consider improving the private friendship if you might be a longterm coopration with them.Uh? It didn't work? Ok,email and phonecall are your powerful weapons. You can CC to their boss,their management repeatedly till they make a promise.Trust me, your skill might be much more than mine,but in this case,It's useless.