- 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
Please check comment file R_NEWCOMMENT/WTFCOMMENT for my comment
Admin
... Holy crap.
Although I don't think that's really given him any job security.
Admin
Ugh, do we have to do this for every 'wtf', It's rarely funny or even slightly amusing.
Admin
Apparently, you didn't check comment file R_NEWCOMMENT/WTFCOMMENT to see his comment...
OT: Damn, that's bad...
Admin
$ sed -f editscript -i *
What's so hard about that?
(Command Line Interface: easy to use, unless you're not sure what you want to do.)
Admin
Any bets the last 20 developers in that job all saw the ever-growing list of nearly identical files and instead of refactoring, just followed the pattern to get it done quickly and give them more time to find another job?
Admin
Your comment is actually listed under comment file R_NewCommentComplainAboutComments_SelfReferentialComment_Comment
Please just use that next time, it's tres tristique.
Admin
Admin
If you are lucky enough to work for an educated customer, great. Idiots need to be separated from their money as quickly as possible to minimize the harm they can inflict on the rest of the world.
Admin
I disagree. I think it's always funny. Keep up the good work!
Admin
Admin
Seriously?
You're in a position of trust. You quote your customer on what it will take to get the job done properly. Doing it right and finishing the job properly will cost 10% of what it will cost to build something unmaintainable.
The customer is as educated as you make him. Not understanding your job doesn't make him 'stupid'. If he understood your job, he wouldn't need you. Do you understand how to wire a house?
I see you've learned nothing from Alex's examples of others' mistakes. The attitude of 'get it done quickly, don't rock the boat, don't manage the project or expectations properly and get the fuck out of there as soon as possible' gives us all a bad name.
Admin
In MS Access?
Admin
Admin
I've had this happen before - come up with an elegant solution only to be told to do it another way. Would have saved time later on as well...
Admin
Admin
Admin
[] You are aware that MDB files are binary [] You are aware that sed works on text files [X] Neither
Yes, reports can be exported, but that's a pain...
Admin
And you're going to try and use that on a set of binary MS Access files?
Admin
To paraphrase fanguad:
using "Winblows" in place of the "Windows" immediately invalidates your opinion. Goodbye, see you next conversation.
And I'd like to add: Grow the fuck up.
Admin
And now, despite itself, like a starship on the event horizon of a black hole, desperate but powerless to stop, your brain is drifting ever closer to the root of the problem. Why in a thousand years would you pay good money to a vendor who puts your text files in such a miserable inscrutable excuse for a filesystem with a secret format, when there are plenty of better tools that are free, open, accessible, and readable?
Admin
Now you're trying to move the goal posts. This is the format the files are in already, what format they would've be better in is irrelevant. They are in MS Access and that's what the person in the story had to deal with. Given that, you suggestion of using sed is asinine.
Admin
Teaching your customer is a continuous process. They hire you because you're good and you have potential to understand their processes. They keep you because you constantly improve their system.
Believe me, I work for some tight clients who originally wanted to pay for nothing and know how to make the mic.
After several years and trust developing, we have contracts in place that allow us to maintain their current system and the right questions asked when something 'simple' is quoted as taking longer than it should because it needs redoing properly.
We have long term plans in place and the client can pick their priorities.
They still don't like paying anything but at least now they understand what they get for their money.
And I will always try to stretch deadlines with them and my boss in an effort to a) do it properly, b) document what has been done and c) force them to sign the spec before releasing the software (Where the spec is written as informally as possible for the layman's benefit - they've got to understand what they're signing and therefore what they're getting)
If you don't work like this, you will quickly run out of new customers or go mad trying to reuse your quick, dirty half solutions (whilst fielding support calls). Or, more likely, both.
Admin
Admin
My brother is a CPA. Bright guy. Knows every last corner of the US tax code. Clueless when it comes to building computer software or buying the right hardware. I used to placate him and just do stuff for him the way he insisted - because he insisted on doing it quick-n-dirty/cheaply. Mind you, I was donating the software effort - but he was paying for the hardware. He ignored the warnings of impending doom. Then one day, my predictions came true. He wound up going back to manual processing for the two months it took me to do it over right. It cost him over $40K. Did he learn anything? No! It was STILL cheaper (in equipment) his way.
In my career, I've rebuilt/engineered the same financial system for numerous employers using 4 different technologies because none of them ever listened to us tech guys. Right? No. Stupid? Absolutely! But it's a good living.
Admin
You miss the point. The suggestion was that the original developer made a mess. When asked to make a slightly modified report, a subsequent developer has two choices:
A good developer would give the customer both options, and may even try to push the more expensive one. The typical customer just sees the prices and that both options have the result of making the modified report, and either thinks the developer is just trying to pull a fast one, or will 'think about it for later' - whatever, they'll usually go for the 'get the job done cheaply' option.
Also, they may think that this "will be the only modification we want", so $300 is obviously better than $3000. Even if they can foresee 5 modifications, $1500 is better than $3000. The problem is that by the time they have done those 5, they can foresee another 5. Now the $1500 is money down the drain, so it's not worth spending $3000 now, since "there can only possibly be another 5 modifications, can't there?", and so on.
All a good developer can do is give the customer the options, and then post the results here.
Admin
Nono, I didn't miss that point and I totally agree - you have to take the situation on its merits. Clearly 3000 for a total rewrite isn't going to happen, but 400 to include time to rework your bit properly and leave a decent legacy I think is just.
And you always give the customer these choices, with the right explanations: That's what develops the trust.
I was astounded by the chap's cavalier attitude towards his customers. There's no black and white, and sometimes you ahve to walk away from the truly crap, shortsighted ones.
But like the teacher with a class of dim children, you have to assume it's your fault and you haven't found the correct way to explain.
Admin
Because it's cheaper and easier (90+% of the time). Close to zero people outside of our profession care about anything else when it comes to any kind of programmable solution.
Admin
No you still miss the point. So you would have reproduced the same retarded structure of having a separate form for each and every variation of invoice in another system, because now you can use sed and you think that is a better solution? If you simplify the multiple copies of the same form down to just one, then you don't need sed. So your suggestion is still idiotic.
Admin
So, if you have all of these "years and trust developing" why would have to redo something? Maybe they trust you to always have an explanation for why something costs more than it should when it should have been done correctly in the first place without a redo.
Admin
Am I the only one that feels you shouldn't charge customers for refactoring? A customer doesn't care if your code is sparkling clean or full of WTFs. They want working code cheap. It's up to you to make it maintainable.
IMHO, refactoring is something that code shops should do to keep their technical debt low and their profitability higher. It should be a fixed charge, like electricity, e-mail, etc. All the necessary stuff that gets business done.
Maybe I'm missing something here.
Admin
In most cases we're slowly replacing a legacy system built out of so much string and blu-tack. In other cases, the business requirements change and altering bits of the system allow us to extend and refactor some bits which were done in a rush.
There always will be some rushed bits. Everything has limits. Know those limits and advertise how long your solution will work for and when it will be time to write something more scalable.
Admin
/me use sed on /dev/kmem
Admin
You might be... Should two cars cost the same if they both run, but one is easy and cheap to fix when it breaks down, while the other is practically unfixable? I'd say the easy-to-fix one has greater value, and therefore should cost more. Maintainable code, similarly, has greater value than WTFy code, and should naturally cost more.
"Working code" is also a relative term. It might work now, but be flimsy enough to be unable to handle tomorrow's load. It might work fine until the server goes down, then be unable to recover properly.
Well-written, maintainable, robust code is better for both the programmers and the clients, most of the time. It's a pity some (most?) clients don't see that. :(
Admin
Umm, CaRL? You've already exposed yourself as a know nothing wanna be fanboi. Do us all a favor and FOAD, or at least GTFO until you grow up and gain a brain.
Admin
I agree with that statement.
But I don't think creating well-written, maintaintable, robust code costs you all that much more, and in the long run, costs you less, because you don't incur the technical debt. Foisting your techincal debt onto your customer -- in other words, making them pay extra for the stuff you should have done right the first time -- makes you less competitive.
Admin
all he really needed to do was
sudo fix my report sudo make me a sandwich
Admin
Ya know, I imagine there would be another WTF if this was all in one file with dozens of checks to modify just a few lines.
TRWTF is assuming something simple in a system you don't know will actually be simple.
Admin
I don't think you should charge a customer for refactoring WTFs out of the code when they never should have been there to begin with. I can see charging them if the WTFs were a result of them pushing to have the project done by an impossible deadline, but often times that's not the cause of the WTF code. More likely it was someone who didn't know what they were doing and management that either couldn't or wouldn't review the code/design.
I'm working on a big project now where some idiotic design decisions were made at the start of the project and now the code suffers as a result. Every time we add something new we just go along with the original design pattern, and it usually breaks something else in the process. It would probably take a month or two of coding to refactor out the original WTFs and it would make the application a lot more stable and further updates would be much easier. Unfortunately my employer would charge the client for the time to fix the issues, and the client isn't going to pay for two man months of development that doesn't add any new features or make any visible improvements. As a result the client is stuck with buggy software and we are left with code that is increasingly more difficult to maintain.
Think of this analogy: you hire a contractor to build you a house, and after it's built you discover that they used substandard materials and construction (e.g., the joists were too thin or not secured properly). Obviously the contractor screwed up and you're living in a house that has structural problems, even though it isn't apparent from the outside. The contractor, not you, should be the one to pay for the cost of repairs to make the house the way it should have been to begin with.
Now back to software, even though problems with source code are harder to see than problems with building construction, in both cases the contractor is the one to blame for the inferior product and should be the one to shoulder the cost of repairs.
Admin
"In Soviet Russia, comment checks you!"
Now THOSE comments never get old!
Admin
Will the rest of the project take two month less time if you write the design bugs out now?
Can your boss take one on the chin and let you finish the project late at lower cost if it costs your company and your client less in the long run?
These may not be realistic but they are good questions to ask yourself. Sometimes you have to cut your losses, sometimes it's worth the freebies for the long term relationship and lower stress levels.
Admin
Admin
This is a good example of "Technical Debt" - where just like real debt, the longer you let it build up, the more of a expensive it is to pay off the interest (in this case the volume of work required to put things right).
The trick is to keep track of the quick and dirty additions to your systems and balance them with a regular clean-up so that it doesn't end up choking your project.
Admin
Admin
Well, I agree if YOU were the person who made the mess in the first place. But, if someone comes to you out of the blue and wants them to make a change to an existing custom invoicing application they have, you would have to be mad to refactor/rewrite it into something decent for free...
A responsible person would give them two (or more) options, 'I'll do what you need now for $x and it'll be expensive to make further changes or I can rewrite it for you now for n * $x and it'll be more reliable and cheaper to make further changes'. The customer will nearly always pick the cheaper option, in which case all you can do is do the best job you can and try to leave a slightly less bad mess for the next person...
Admin
No - 'Doing this job properly is going to cost you $3000 because the last developer you hired for this project was a moron'
Obviously you don't do this if you were the moron, or you are employed by the same company as employed the moron, but if you are a new developer it's quite easy.
If you were the moron, then you should take it on the chin. If you are employed by the same company as the moron, then you take it back to your mutual employer and let them fix the moron.
Admin
Is that really responsible? Here's how I see that playing out:
You: I'll do it for X, or I'll do it for 2*X and it will be cheaper to make further changes. Customer: Here's X, just do it. You: Ok.
Months later... Customer: Please change something? You: I'll do it for 4X. Customer: Why, it only cost X last time? You: Remember what I told you? Customer: Aw c'mon, I've seen you guys work miracles before. ---or--- Customer: I don't like your attitude. What are you trying to pull? I'm paying X and that's final.
If you're lucky, your boss will back you up. But I've seen, more often than not, bosses cave to the customer and you'll wind up incurring more techincal debt.
Admin
Well, sometimes you're "forced" into writing WTFs, usually because of time constraints (quick-and-dirty coding) or changing specs (new specs being tough to implement due to them being unforseen or out of the initial scope).
At a project I'm currently working on, we're being faced with just that. New changes would require some massive refactoring in order to code them properly. We're not being given enough time to do this, so we're forced to pick the least WTFy solution given the time constraint. Trying to convince the client that spending more time now will prevent this from happening in the future is futile, for several reasons, ranging from sheer hardheadedness on the client's part to our project managers' nearsightedness and lack of support/consideration for their software developers. (That is, the client wants the next phase deployed NOW, no matter what... and our PM's don't care what we have to go through, or what we'll have to go through in the future, they just want the client happy, NOW.)
Meh, this turned into a rant... sorry!
Admin
"Winblows" -- how's that?!? It's my opinion (after having to use it as a developer for almost 20 years!), and I feel like expressing it. Don't tell me to "grow up" because I have an opinion. People that don't want others to have opinions need to "grow up". I ain't trying to get you guys to switch to Unix, and could care less what you write about it! Give me the same treatment.
This stuff is said from experience, too!
Is this better....?
alias f='rm -rf $1' f /windows
Admin
I'm quite enjoying all this arguing today, please continue!