- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
</dev/null
Admin
Hate to say it, but Dave is right. Dump the change on a to-do list, and go generate some value - elsewhere.
Admin
Dave was right. In REAL WORLD, someone has to pay for everything.
And if someone is only playing with technology and has no real results, he has to go. Life is not a university.
Admin
Dear Martin & Not Dave -- I'm happy I don't work for/with you.
Admin
I find that the shittier a company is, the better they are at bullshit and trying to appear like a good place to work; some of them are intelligent enough to hide all the blemishes until you start the job, at which point it's too late. I've worked for a handful of places myself that were good for buzzwords and that was it, and knew how to hide all the crap to lure people in. I referred to them as "Siren Companies" after the Siren of Greek mythology that lured sailors in with a pretty face, and then drowned (or ate, depending on the story) them once they got close. And, sadly, there seems to be a ton of them that operate this way, being dishonest to get unaware developers to sign on, and then making life miserable for them.
Also I totally disagree with the, I hope, trolling comments above. If you are a consulting company, which it seems this company was, then your goal is to also provide scalable and reliable solutions to your clients, not just throw something together and move on. I find that a disturbing number of developers adhere to this mentality of "just enough" and that usually translates to "just enough to not bite us in the ass for a few months" which I have found to be insanely destructive behavior. If you're only looking at a few months ahead and not further, you are either a scam artist or desperate.
Admin
I'm surprised nobody here ever thinks about why small businesses run by developers/IT professionals/etc fail and bite the dust. This is a classic example of why Dave's business is still running. I'm not saying his throwaway comments about Rob are good, that's a different problem.
Many people here that don't own/operate a business. Yes, as a developer, shock-awe-horror there are bugs, there are issues that will lead to performance problems, etc etc. But, in business, if the client signed off it's delivered - and they will be required to pay to resolve any issues outside the scope and agreed support plan. Would Stewart do the work for free, in his unpaid time? On time off? Weekends (assuming he isn't working through them)? I would bet cash money the answer is no. Same principle.
This is not a-hole logic, this is how businesses must operate, otherwise they will fall over and die fast.
Admin
Surely, the ideal support contract is something your clients will never have to cash in on.
At worst, a performance issue in support should require a new database index or something. As time goes on and the database gets fatter, this performance issue will be monkey-patched in more and more hideous ways, because the after-the-pain development work required to fix it properly is guaranteed to cost more than the support contract is worth.
Dave's plan: support money in, increasing workload over time. Fixing it pre-emptively: same support money in, little bit of work up front, no increasing workload for this bug.
Admin
Much as it pains me, I have to agree with the others that Dave is right in this regard. If he allows his developers to polish turds like this, they won't leave enough time in the workday to write the code the company is being paid for.
Not that I'm saying the practises themselves are right. The company sounds like anarchy and crazy expectations. Hiring interns and graduates and expecting them to be up to speed and churning out code in 2 weeks is insane. Talented developers with years of experience under their belt, fair.
Allowing people free rein over the technology was the major mistake. Much as I also dislike paperwork and process, there should be some structure and standard approaches. Otherwise it becomes impossible to hire the right type of talent to maintain your systems and you wind up in exactly this situation.
Also somewhat rare to have a guy in charge who is not only technically skilled (agrees with his developers) but has enough business sense to keep the company afloat!
Worst of both worlds. Good article.
Admin
Sure, Dave is completely right about how he should run the business. Until the customers figure out that the products are complete crap and decide to pay a competitor instead, anyway.
Admin
Not really. Consider a performance related bug as described. You could fix it in advance and hope that makes the customer happy. They may well have not even noticed or have a problem. Or you can wait til they complain and potentially save many man hours fixing a problem the customer doesn't care about.
Admin
I also agree that Dave's reasoning is sound. Or at least it would be, if there had been any reasonable thought put into the initial development of the software. Throwing bunch of interns at the project with what sounds like no oversight or standards is a pretty terrible business plan, but Dave probably didn't read that post on the blog he gets all his business "acumen" from. A poorly managed company with poorly skilled developers will develop a poor reputation and everyone will end up.. rich?
Admin
Most "Consultant" companies are con artists.
They "design" a solution so incredibly convoluted that only their consultants can maintain it. Nobody else wants to touch this "solution" with a 10'-pole.
So they suck your money not only once, but forever. Parasites, effectively.
Admin
Stewart missed a great chance to say "I'm sorry, Dave, but I can't do that." Ok, srsly -- whether or not the performance-clogging software should be preemptively cleaned up depends a lot on just how fast it'll get how bad. How many dailywtfs have we seen here from the customer side, where the supplier's code sucks, fouls up, and causes major delivery problems for the customer -- after which a mad fixit run by either the supplier or the poor wtf-ee in the customer organization patches things just enough to run a little longer? Somehow I think Joel Spolsky is a lot smarter and a lot richer than this particular Dave; Spolsky code never gets released to customers with known CharlieFoxtrots waiting to happen.
Admin
That depends a lot on how many customers, what kind of customers, and what kind of workload. In my day job, I work on a realtime high availability and fault tolerant software.
A bomb like that would be grounds for immediately delaying the release as long as it takes to fix it, because it just doesn't meet the needs of our customers.
Admin
Dave is right... until their client turns out to be someone competent enough to tell when the application is handling too much data or not. In that case Dave either loses the client, or does the job he was supposed to do (or to tell to do). For free.
Because there's another thing to put into consideration: the client's satisfaction. No client likes bugs or sluggish responses. If they keep on finding them, they might consider moving to another provider. Sometimes all you need is a little investment to keep you client content, so you don't have to do it later with a pissed off client.
Admin
Never enough time/money to do it right, but always time/money to do it over.
Life goes on (SIGH).
Admin
I completely agree in principle but still find myself struggling over who to side with in this story.
I've worked too many places with too many weak developers that did absolutely nothing but cripple productivity. Cruelly, I was always the one who paid the price. You know how it goes: team of incompetents is way behind, brings on an expert, handcuffs the expert, situation doesn't improve (surprise!), blame falls on the expert. The real problems are never dealt with and they just push the failure onto end users in the form of lousy software and non-existent support. More of that type of duhveloper needs to be fired and experience chronic unemployment.
On the other hand, I've interviewed at chop shops like what Dave is running. They end up with a different kind of weak developer, the slapdash drag-n-dropper. Web development is full of them...can't validate input, handle exceptions, align elements properly, etc. But they sure slapped that together fast and that's all that matters. Until the chickens come home to roost and everybody's screaming "what does 'their was errors files dleted sorry try latr [yes] [no] [cancel]' mean?!?!" Sometimes they proceed to scramble for an expert, lure one in, ignore their recommendations, and...
Admin
Oops, wrong reply button, I was agreeing with DocMonster :/
Admin
Using the business arguments as read here, we'd all be driving some extremely adequate Model-Ts.
Admin
Hi. I've been working for +10 years in the software development area in several companies inside Mexico. Need to say that the same principle applies here. I was in the same position as Stewart, but i learned (unfortunately in the hard way) that if an application is works and the client hasn't reported anything wrong, Is better not to touch it.
Several years ago I worked in a gas company and found an issue with a screen inside an administrator application (a filter screen appeared so small that was impossible to see the filter values in the screen). But that application was only used by the development team. the clients wasn't complaint at all. One day I decided to investigate and found a patch that solves the problem. One day i decided to patch the administrator application and the issue was fixed, but the system went into a several code errors. The department manager was so angry because the patch modified also the clients application and nobody was able to sell anything because of that error (basically the company was loosing money). I had to rollback the patch but we spend several hours because there was no backup available and, the last backup will cause sales lost and was, simply unacceptable :(
Admin
Yours sure do.
Admin
Jesus Christ
Admin
Disagree with Dave. Mediocre crap is the enemy of great. Code WTFery hinders the code I have to write on top, not to mention my debug/run experience. It's ultimately bad for everyone. Thankfully I get opportunities to take out the trash.
Admin
I've been through pretty much this same situation. I found a way of speeding up a certain web site by like 30 to 40 times. I took the info to the boss and I thought he would be pleased. Not so. The site had not asked for such a speedup, so it wasn't going to go into production, not unless they someday asked for it. I started looking for another job that minute.
Admin
Two things I want to say.
First, I'd think about escape plan the minute I heard about "dynamic team of programmers" because with no exception, all companies that I worked with and use this line to describe their team are using it as exactly the same meaning as shown here.
Second, the way Dave stop Stewart is the same as how my boss stopped me fixing some potential problem in the application, and is one of the reasons that I choose to resign now.
Admin
Sure, some clients will move away, but there are always stupider clients to replace them with. I've seen many smallish businesses like that - the owner isn't much good at running a business, but is just great when it comes to bringing in enough work that his shortcomings don't have hugely negative effects.
The downside to working that way is that it limits the size a company can grow to (because it requires continual input from the boss), but other than that, it's very viable.
(NB: That's just how it it, not how it should be.)
Admin
This story is a necessary consequence of the type of business Dave is in.
Yeah this is bad, but it's an entirely predictable set of choices that led here. The Real WTF (tm) is that Stewart is so shocked.
Admin
Precisely, Dragnslcr. The incompetently implemented product will eventually crash, at which time the customer will pay for the incompetence.
The company described is trapped in a mode of operation that doesn't allow them to develop good products. The only solution for a competent employee is to work elsewhere.
It is fraud to knowingly sell a defective product and then make the customer pay to fix it when it breaks.
An ethical company will try to improve its products over time and invest some resources to do so.
Admin
Makes sense if the Customer doens't know the kode behind the app. As a person who is often a Customer of small apps i really do not care how it Works and how well it scales. i might not need scaling. and it if work good enough then i am ok with it. something is better than nothing. i am not a developer and recently i decided to help my department by writing a macro which should be in use until the real devs make the better solution. we required the app from internal IT a year ago and they still haven't delviered. so i did what i could with the tools at hand. and it works well (far from perfect but so much better than what we had before). it wont' scale well of that i am sure. as soon as we get twice as much inputs as we do now the whole thing will slow down to a crawl. this could happen by the end of next year at current rate. so i really hope we get the app we were promised by that date.
Admin
I realize this is a week or two old.
I'm curious, how come that in these articles, quite often it's about a guy, pictured very positively, hinting there can't be nothing wrong with his attitude and/or experience, but who is at the same time inadvertently described as having quite tiny experience - and we always mock the environment he's in. For example, this Stewart dude, after leaving his one and only IT job at an university (so, having learned practically nothing), suddenly knows everything about everything on the new job. Whatever... I'm not saying that the environment in this story, as described is any good (I agree it probably can't be more retarded), but Stewart wouldn't know how to recognize that and even be able to tell you, the author, anything about it. Half of these stories are WTF-ly made up, I'm sure. And, so is this one. And that's my opinion as to what the today's [well, "that" day's] WTF's really is.