- 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
The 31st rule of Quick Fixing states: "High standards and an empty wallet is worth the wallet."
Admin
Before? I'm writing something like that right now. The tables were created a year ago in firebird, then moved to postgre (when fb couldn't take the load anymore). Of course normalization looks like "create separate table for data from each device". Deadline is in about 3 weeks and no one has time to make things properly. This is how shit happens.
Captcha: inhibeo (propero standardo)
Admin
On the upside, I've done such thing in previous job and there was always some other fire to put out. Now my boss says "never again such lousy project". After everything works there will be time for refactoring and this time the code has to be made properly. Probably there will be complete rewrite in some other language.
Admin
When considering the advantages and disadvantages of adopting "new", it's amazing how many people are too retarded to consider training costs.
Imagine if you work in a team of 20 people, and some butt-head goes and adds LINQ. Now 19 other people need to waste a day each learning LINQ. Let's say (for the sake of round numbers) that a developer costs $100 per day. That butt-head just cost $1900 for a start.
Of course when someone "learns" something in 1 day they're never an expert (they start with zero experience), which means there's ongoing confusion and mistakes that would probably double the initial cost. This means butt-head actually cost $3800.
However; that assumes that nobody is ever replaced. Maybe over then next 5 years 8 different people will be hired and will have to waste time learning LINQ (at a further cost of $200 each, or $1600). That brings us to a very rough total $5400 caused by our beloved butt-head.
Total cost of staying with the existing SQL that everyone knows would've been $0. The senior developer maybe spent 30 minutes to fix butt-heads stupidity. The senior developer is smart. He spent about $6 worth of time to avoid $5400 of costs.
Admin
It sounds like a nice way to approach things, but my experience has found the contrary.
Remember we all work in version controlled systems.
It is best that each change you make is just one single issue. A refactor should be just a refactor, a bug fix should be just a bug fix.
If you have to rollback your refactor because you made a mistake, you really don't want to rollback the bug fix at the same time, reintroducing the bug.
Fix the bug. Check in. Refactor. Check in again.
Admin
When I am actually typing a comment, whether it is a new one, or a reply to yours, there is no "[Expand full text]" visible. Nor any other comments other than the one I am replying it.
If I want that I have to right click and "Open in new window".
Admin
Admin
I couldn't agree with you more! Don't try to be the hero, cus you might wind up looking like the asshole. If you REALLY want to obliterate the bad code, you have to rewrite in your SPARE time. I'm a stickler for writing clear, concise code, but not everyone has that knack.
Admin
TRWTF is stupid junior dev who thinks that being a programmer is about excellence and awesomeness. It's not, it's about providing working solutions for minimal costs and as few bugs as possible.
He doesn't like this code because it is inelegant. His solution is to rewrite it all. Fuck off.
Working for a typical corporate is about getting as much done in the amount of time you have, which is 50% of the time needed. This doesn't matter, since (and this is the bit WTF-jr in the story doesn't get) the software is not the product, it is something that allows you to deliver the product.
Some of the people on this site get it. The others don't work in corporate environments, they work for software houses - where the software is the product.
Think of corporate IT as a factory production line. The device that sticks the labels on the bottles doesn't do it quite right, the labels go on at 5° angle. It still works, people will still buy the product, do we spend a bunch of money fixing the labeller, or do we finish the shrinkwrap machine so we can ship some product?
Note that I'm not saying that corporate IT cannot produce excellent code. That is your challenge, provide unit tests for your code, deliver great code. You just don't waste time fixing code that don't need fixing, just so you get the warm'n'fuzzies.
Admin
OR
you could stop whining about the need to use one tab for the article, another to comment. What, does your computer only have 512 MB of RAM? Or maybe you're afraid you'll run out of WHNDs?
Admin
Ah yes, the good ol' "let me show you what you didn't consider using an example that doesn't consider everything" argument.
You pay no mind, at all, to the productivity improved by acquiring new skills. By your one-sided rationale, no one would ever undertake any kind of automation, optimization or training because it all counts as cost up front. Where's the return factor? The entire reason software developers exist is because they're a ROI after an up-front (or even ongoing) cost.
You also seem to think that the company should expect to lose productivity just because their developers don't know LINQ. That's obviously not true - being a professional means constantly learning and that happens over and above the hours you spend working. That's how it is for doctors, how it is for lawyers, that's how it is engineers and you-name-it. If you happen, and I think software development is one of those things, to be able to learn/improve while doing the job that's awesome, but if you think you can be a continually relevant and employable professional based only one what you pick up while on the job, you're kidding yourself. Robert Martin says 20 hours a week, but I think that's a bit steep especially with a family. At least 5, more preferably 10, hours a week should be spent on learning stuff not directly related to what you NEED to do your job.
What does that mean? It means that when it comes time that someone wants to use LINQ in the project, just about everybody on the fucking team that works using C# should know what LINQ is. There's admittedly a gray area when something is an emergent technology or feature compared to when it's been around for a while - but that is the argument about putting it in to production. It's the fact that it's leading edge that should make you uncomfortable about throwing it in to a product of any critical nature, not the fact that oh, boy, doofus developer goes home every night and doesn't ever learn a damn thing.
Also, my company gives everyone a yearly budget for training, and I think most decent software companies do - and its a use-it-or-lose-it type deal, so there is an incentive to at least learn something new every year. That, of course, is in addition to at least one book a month I read, as well as trying new languages and frameworks at home to make stuff that I have no plans to do anything with but throw away.
Admin
This is not how things are heading. Have your tried using iOS or Modern UI on Windows 8. Full screen apps.
Admin
This this THIS. If you are a professional developer you should at least be FAMILIAR with emerging technology in your area of specialty. You don't have to be all evangelical and wanting to rewrite everything in the latest and greatest fad, but if you give a "deer in the headlights" look when something new is mentioned and have zero clue what it is or what use it could be, you aren't a professional.
I work(ed) primarily in C#/ASP.NET so let's use that as an example. If you are a .NET web developer and you don't have the foggiest idea what ASP.NET MVC is, or Entity Framework or LINQ or anything like that, there's a problem; I would go so far as to say that any developer who isn't familiar with the available open source projects in their space (e.g. NHibernate) has a fundamental issue as well. Now, nobody is saying you have to have a dozen home projects to learn MVC, or try to shoehorn every project into using MVC/NHibernate/library-du-jour, but if a developer on your team (whether they've been there one week or 10 years) suggests that a new project could benefit from being done in MVC, the real problem is a developer (senior, junior or otherwise) who is all like "What's this MVC thing? I've never heard of it. Why can't we just use WebForms?" without a second thought or any consideration or discussion.
Maybe MVC isn't the best choice for that particular project; maybe it's a "thick" web app that would benefit from the WebForms model, but it shouldn't just be "Oh we'll just do the same thing we've done for the past five years" on every project either. This field advances, and good developers advance with it by at least having some cursory knowledge of new trends (whether or not they use it, the point is to know at least a tiny bit about it so you could, in theory, expand on that knowledge for a project).
I maintain the notion that GOOD companies operate like this. Good companies don't reprimand or fire people who recommend better ways of doing things; instead, they at least consider the possibility. Good companies understand that if you bring in a developer with let's say 5 years of experience, you shouldn't dismiss anything he says because he's the "new guy", since he's not a newbie just new to YOUR company, and could provide some insights that you didn't consider. GOOD companies encourage evolving with technology, not doing things exactly the same way the past 5+ years, without a care to advances. Good companies want independent thinkers who can provide insight/suggestions to improve their operations, while bad companies like the one in the article want mindless drones.
Admin
Firefox is now on a six-week rapid release schedule, and it doesn't seem to prevent them from doing refactoring (although there were some really big refactorings under the old schedule).
Admin
Again, it kind of goes back to company/team mentality. A good team with competent developers usually uses principles and practices that encourage constant refactoring and enough abstractions, backed up by unit tests, to keep the code relatively clean or else keep the smelly hacks isolated where they can be addressed later without polluting the rest of the code.
On the contrary a poor team always focuses on "tasks" and getting things done as quick as possible without concern, the overall notion being that there's always some new feature that precludes routine housekeeping or even just following the Boy Scout Rule while making a change to the code. A developer on this kind of team will, even if changing a module that could use refactoring, make a quick hack and move on to the next task when they should have taken a bit longer to do some cleanup of the code.
Again, I have seen this behavior firsthand as well as it being showcased in a few articles where a lazy developer will understand that things SHOULD be refactored, but instead of actually doing it will just copy/paste a change or add a hack, close out the task and move on to the next one without any thought.
Admin
Heh. Ok, fair enough, but the diff tool would catch that because that's more than a change of whitespace, that's adding whitespace where none was there before.
Hmm, or would it? I shall have to experiment sometime.
Admin
No it's about being given responsibility and need-to-do tasks and ensure they get done in the way you see fit.
Yes you need tests and bug / issue databases but then it goes too far when every refactoring or code improvement change has to be justified by tracking it against such databases.
Developers are paid a salary, not paid by line of code changed, and therefore they don't have to justify them based on that they are being paid for these changes.
Developers will be more efficient when they are in charge of the code they are maintaining and not too restricted. Source control and isolating things into proper components allows such changes to be made in a safe and tested environment.
The environment of "we don't touch it unless it fixes an issue" is the WTF.
Admin
Michael: So if you don't want to change it, why do you have a comment reminding everyone that it needs to be changed?
Senior Dev: Don't pay attention to the comments. The code works just fine.
Michael: Why not remove the comment then?
Senior Dev: NO! Too risky. If it ain't broke, don't fix it!
Admin
I was surprised to find that Beyond Compare doesn't think there are any important differences between
and Maybe you could edit the BC's C grammar to make it understand, if you really cared.Admin
Whatever... Sometimes you are too freaking busy to be redeveloping code that management can't "capitalize" on... As much as I agree with the OP, the old graybeards are right as well when it comes to certain corporate environments. Hope the OP finds that job that DOES have the time to invest in a good clean solid no-slop approach!!! I shall, of course, be envious.
Admin
I work on-and-off on a system that started under 286 Xenix.
I'm happy if the dinosaurs just write ANSI-style function definitions instead of K&R, and can remember that the stack is big and the heap exists.
I wish I was kidding. God, do I wish I was kidding. Just figuring out the hundred global variables is enough to drive you crazy.
Admin
Because 'producing a better version of firefox' is the only goal of people working on firefox, it behoves them to act like this. Same goes for most other open source software, and anything where software is the product.
This is why reading things like JoelOnSoftware is good and bad. Joel used to work for MS, making software products. He now works for himself, making software products. He has to make his software great, and so he can bang on about how to make wonderful software - but his environment is not the corporate.
In a corporate environment, we are not trying to build the best "Phone Billing Manager Export" program in existence, we just need to export the right data at the right times. Yes, the code could be written better, but doing so delays us from making the now essential changes to salesforce, and doesn't net the business anything, apart from IT's warm'n'fuzzies.
In corporate, IT isn't the product, it's the solution. Some people in IT forget that, like the junior dev in this story. They think that since IT is so important to them, IT is the product. They need to get a clue.
Admin
We don't touch it unless the business tells us that it is important. It works, it does what the business wants it to do, it's a little ugly, so you want to stop working on what the business needs, and instead work on what IT wants.
That's the WTF.
Admin
No, the business needs to get a clue that having clean code facilitates easier changes and additions down the road. That's always the problem in Corporate IT: You're too focused on "exporting the right data at the right time" that a year later when you need to export another type of data, or the data you need changes, it introduces a ton of other bugs because you hacked some shit together the first time instead of using real design patterns and software engineering principles.
Constant refactoring, heavy design patterns, TDD/testing and the like aren't just the domain of software companies and OSS users, they should be the norm EVERYWHERE because what they do is focus on maintainable, scalable and extensible code, so later on when the business needs change (and this is doubly so in a corp environment where things are always changing, sometimes slightly and sometimes drastic 180 we're changing our business model changes), the team can respond quickly without introducing new bugs or adding new kludgy hacks to the system.
Admin
It's not "meh." Revenue generating code vs an ego trip is a lost battle already.
Admin
OK, I'ma gonna ask you: "Why havn't you posted this to TDWTF yet?"
Admin
Because so many software development teams are badly managed, and often treat developers with so little disregard that they just want to leave.
Firstly, the best size for a development team is 2. Of course if your software is a very large scale, then have 2 teams of 2.
You then have project managers who discuss the "whats" not the "hows".
Issue tracking databases are intended to be there for project managers and testers to raise issues.
For refactoring exercises that are going to take significant time, you should clear with your project manager its benefits and how it will not interfere with getting delivery on time, or why delivery needs to be delayed for the better purpose.
For small changes that will take a relatively insignificant time to implement (like this one) you should not require such permission.
Of course, just because I'm giving a general licence to change the code as you see fit does not mean you do not have to adhere to standards: use source control, ensure your code is properly tested, and it should also be properly documented.
With the particular example, my response to the developer that "yes, we have had plans to change that, as denoted in the comments, but we have not yet had time as we have to ensure delivery is done on time, and we have had actual bugs to fix which are higher priority. Also we need to ensure any change if adequately tested. Once we get ahead of schedule we can work on it. In the meantime, if you're stuck for something to do (i.e. you are blocked on any of your own issues) you can get down to writing some tests for the change you wish to implement".
Admin
TRWTF is that they're considering to use ResultSetMetaData just to write type-agnostic code. Using getObject and setObject would have worked just as well, and with the exactly same amount of type safety - i.e. DB complaining if the types don't match.
BTW for those still contemplating macros: It's Java, not C++.
Captcha: verto - "I turn around". Heh.
Admin
The code itself isn't really that horrible. The WTF to me here is Michael. Where what was it? Three weeks into the code he was hoping to use something that scored him points in an interview to score further points with the dev team? Sounds like a guy who has off standards and priorities that can't take criticism.
Maybe a WTF is also from the interview. They set-up his expectations perhaps that he'd mostly be refactoring code in the beginning?
Admin
The macro wasn't a serious suggestion. It would be worse in my opinion than the code that is already there.
The template was a more genuine possible solution, the point being that this pattern is being used "all over the codebase" and the template makes it reusable.
Of course if this is Java you would probably have the base object of the input source and the base of the output source and you'd need to set up a schema object, which could be done as an array (but a string doesn't work that well). I would also use enums in the array.
If you want to write it a line at a time, you might use an enum, but the code as it stands is far better than using column names where it has to look up the name for every record you like.
Admin
Protip for the fresh out of college: Your colleagues are going to be idiots. It will be a feat in itself that they can code at all, let alone code something that is easy to read, understand, or maintain. Quite literally, they will be "code monkeys". If you're reading this and telling yourself "No! mine aren't...!" then guess what? You're one of the code monkeys! Now you know. In a perfect world there will be no political boundaries to juggle, but in the real world you'll be forced to put up with it and do your best to workaround their incompetence. You'll probably have to put up with seeing them being praised for their speediness at times too, while you go unappreciated, despite the invisible costs down the road of having to maintain the garbage. I can sympathize with the OP.
Admin
Well one improvement is you probably could no longer use grep to investigate the code base. This is important, you want to nip stuff like that in the bud.
Admin
this is sort of the programmers "chicken vs the egg" ultimate delima! do you spend time knocking out paying projects or all of your time rewriting old code to fit into your personal view of clean and efficient... and as sarcastic as that may sound, it will be a different answer for everybody what "clean and efficient" mean, want proof just read the comments off of any one of the WTFs about how many ways there are to do something. i think when it comes down to it simply for a bug fix, fix it (if time re-factor it), but dont just be changing code to be changing it. i also consider a routine that takes so much time to run due to inefficient code that it starts to negatively impact the customers to be bug as well so i believe all that has to be weighed in not just start rewriting everything, remember KISS (keep it simple stupid) and if it works, leave it a lone are really good practices in today's competitive programming world! my $0.02 for what its worth, and if this is enough to "honk off" this new programmer and get him to move along, he better thicken up his skin because there's way worse crapola out there in our field waiting under every little leaf, blade of grass, class, method, function, etc. this is not a field for the faint of heart i fear!
Admin
The WTF isn't that refactoring was being delayed, it's the attitude that leaving it be is OK. Code doesn't exist in a vacuum, it exists to make a problem go away.
The problem with crufty code isn't that it doesn't make a particular problem go away, it's that when the problem changes over time, it's difficult to amend the software to meet the required changes in need. Because of this, you have solution that may be cheap to begin with but becomes increasingly expensive over time.
Delaying a refactor increases expense over the long term and works somewhat similar to interest on a financial debt.
See: Technical debt. http://en.wikipedia.org/wiki/Technical_debt
Admin
And if it gets too high the only answer is "technical bankruptcy" i.e. scratch it and start a rewrite.
Admin
Amen, brother!
Admin
(ignore the first reply... forgot to quote)
AMEN Brother!!
Admin
"Re-factoring anything is a sure way to introduce new bugs. "
No, it isn't. Seriously, do you code blindly while drinking a gallon of whiskey - or do you not make sure to have unit-tests to prove that any changes haven't broken anything?
I think way too many grey-beards might be residing here.
Admin
The developer is proposing replacing code that maps a list of strings/ints into some sort of row structure (and then adds that row), identifying what belongs where by position.
I am fairly certain that there is no way of rewriting this code without putting this mapping in another place which unless that this same IDENTICAL mapping to row structure is done in multiple places in the code, will result in anyone referring to this mapping needs to both find the code where it is used and the external mapping. Looking in two places is more work than one.
About the only thing I would have changed in the code is to put a comment identifying the associated column name; I would do this when the mapping is being changed.
Admin
You should see our PHP codebase.
An excerpt: