Tag Info

Hot answers tagged

169

Schema Changes Fetch by order --- If the code is fetching column # as the way to get the data, a change in the schema will cause the column numbers to readjust. This will mess up the application and bad things will happen. Fetch by name --- If the code is fetching column by name such as foo, and another table in the query adds a column foo, the way this ...


143

Non-techies aren't idiots (for the most part). They can understand a technical argument if you keep it high-level enough. Pick a task you thought should be simple, and walk them through why it's not. I expected this change to be one word in one file. The most likely place to change it seemed to be here, but when I changed it there, it only worked ...


86

Code structure, style, technical debt are one thing that - at least initially, until the client trusts you - you're going to need to live with. Security vulnerabilities are another matter. Personally, I would do an estimate based on the work required using the existing structure and style while making it clear that there are significant issues with the ...


74

Some great suggestions here on how to convey and communicate this to the client. Hopefully they will pay off for you. Major red flag here! If the client asks you not to make any changes other than what you've agreed to (HTML and CSS) I'd pass on this project and withdraw my bid. Even with a written and well communicated overview of all of the flaws and ...


72

Imagine you have to use someone else's code designed as about below: class Messy { String concat(String param, String str) { /* ... */ } boolean contains(String param, String s) { /* ... */ } boolean isEmpty(String param) { /* ... */ } boolean matches(String param, String regex) { /* ... */ } boolean ...


65

Think about what you're getting back, and how you bind those to variables in your code. Now think what happens when someone updates the table schema to add (or remove) a column, even one you're not directly using. Using select * when you're typing queries by hand is fine, not when you're writing queries for code.


58

Torvalds is talking out of his ass here. OK, why he is talking out of his ass: First of all, his rant is really nothing BUT rant. There's very little actual content here. The only reason it's really famous or even mildly respected is because it was made by the Linux God. His main argument is that C++ is crap and he likes to piss C++ people off. ...


45

Technical debt is like financial debt. You take it on (hopefully) strategically in the development of a program with the intention that it will be paid off in the future. Sometimes people make poor technical debt decisions (such as running up a credit card), but sometimes a certain amount of technical debt is just normal. Deciding not to devote the time to ...


38

Another concern: if it's a JOIN query and you're retrieving query results into an associative array (as could be the case in PHP), it's bug-prone. The thing is that if table foo has columns id and name if table bar has columns id and address, and in your code you are using SELECT * FROM foo JOIN bar ON foo.id = bar.id guess what happens when ...


30

I don't believe in bad patterns, I do believe that patterns can be badly applied ! IMHO the singleton is the most abused and most wrongly applied pattern. People seem to get a singleton disease and start seeing possibilities for singletons everywhere without considering alternatives. IMHO visitor pattern has the most narrow use and almost never will the ...


29

Explain and possibly demonstrate the flaw When it's your word against his, everything you say could just be hot air as far as they're concerned. Once you show them how their app can be abused via SQL injection, then suddenly you're a person to be trusted. You're going to need credibility in order to renegotiate. And this is enough of a game-changer to give ...


27

In a word, yes. Anyone that tells you otherwise is probably, at best, mistaken. However, the key is to build on your experience to write code that is less bad. Resist the temptation to put in something to make it "just work" if at all possible, because it won't. You still need to follow some sort of process (be it your own, or your company's, or some mix ...


25

I've never (in 20-odd years) come across intentionally bad code, but the examples you cite seem (to me at least, but IANAL) to be attempts to defraud either an employer or a customer, so you probably have a legal obligation to point it out to your manager.


25

I'm sorry to tell you, but not all jobs are full of sunshine and glamor. The majority of development tasks involve drudge work like this. Sad, but true. You are tasked with an important job, even if it's boring to the point of watching paint dry. It's important for two reasons: 1. It add much needed logging to a large system so that when something goes ...


24

Keep a file of candidate code snippets for submission to thedailywtf.com. Even if you don't really intend to submit them, it gives you a bright side to finding some code that's even worse than average.


23

'But it works now' is the standard management response to the legitimate frustrations of software engineers. The first thing I would do would be to compile the documentation (if any) and use that to demonstrate contradictions between the code and the documentation. If you can, put together a comprehensive suite of unit tests. Run these with every change so ...


23

At some point you have to be in charge. Code is done a certain way or it is done over. If he can't at least correct his mistakes, he has to be let go. I'm trying not to overly simplify this. There is a difference between an inexperienced coder who makes mistakes but is willing to learn and someone who thinks they are always right and does not recognize ...


23

Let me play the devil's avocate here. Maybe all of your team, with the exception of that programmer, are the ones who are inferior, and he really is a brilliant programmer. Imagine if, say, Linus Torvalds (let's pick a poster boy for accomplished programmer) for some reason fell into a situation where he is working in a team of moron programmers whose ...


23

How can I change my mindset to focus on task instead of contemplating how bad is the codebase I have to deal with? By realizing that by making this assumption: In this question I assume that obvious solution, i.e. fixing the bad code is not possible/applicable: it works, is too big, fixing it would take too much effort, it will be soon phased out, ...


22

IMO you are already mostly going about this in the right way: you are not suggesting a ground-up-rewrite because "the old code sucks", but fixing one thing at a time. To avoid feeling like you are blaming the old team, just imagine that they probably had to produce this code under great time pressure. Management at that time probably didn't really ...


22

if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc. Yes. I've been that guy. And I've learned that it's a terrible thing. It's all very well for you, you don't have to learn something new. But what about the rest ...


22

Querying every column might be perfectly legitimate, in many cases. Always querying every column isn't. It's more work for your database engine, which has to go off and rummage around its internal metadata to work out which columns it needs to deal with before it can get on with the real business of actually getting the data and sending it back to you. ...


19

I started this as a comment, because at first I thought it was an aside, but it probably really isn't. I would fully document everything that you feel is should be redesigned, and why (what happens if they don't make the change), and an estimate on fixing the issue. I would be particularly meticulous with anything you perceive as a security risk. I would ...


19

Sometimes you have to understand these things in the context they were concieved in, then built in, then maintained in. Some of the worse offenders that I have seen probably started out as very nicely written programs. You can see a bit of well-thought out architecture trying to poke out through the mess. But as it happens, the requirements change during ...


16

If the team is in a crunch then something was done wrong. Missing deadlines is a sign of poor planning and estimation. Acknowledge that the deadline will be missed and solve the issue. Sometimes you don't have control over the planning or estimation. Identify who does and ensure that they know this was done in error. In a situation were the deadline cannot ...


16

I've always thought the dangers of C++ were highly exaggerated by inexperienced, C with Classes programmers. Yes, C++ is harder to pick up than something like Java, but if you program using modern techniques it's pretty easy to write robust programs. I honestly don't have that much more difficult of a time programming in C++ than I do in languages like ...


14

I was in a similar situation, tasked with cleaning up a large body of poorly written, massively copied-and-pasted code. To maintain my motivation and my sanity, I wrote a script called current_score that counted the LOC in the project (which steadily decreased, as I eliminated duplication and switched to better algorithms) and compared it against the LOC ...


14

You should choose better design if: You are going to be taking over a large part of future coding Better design isn't more expensive to the client in the long run. For instance, I have witnessed multi-month "refactorings" for projects that were discontinued by the end of the year. You should choose "same bad style" if: You're just helping out. It's ...


14

Remember that the client is going to you for help with maintaining their application. It is your job as a professional to point out any issues you find with their application. The client likely has no idea these issues exist and they should be made aware of them. Explain these issues in a manner that they can understand and let them decide how they want to ...


13

•if you're coding with ease, it feels (or actually is, in short run) just quicker to snap out your own solutions on the spot, without turning to libraries, preexistent functionality etc. Skilled in the language but not the tools. That's not really even being a strong coder. It is just polishing one skill (language knowledge) and allowing another to get ...



Only top voted, non community-wiki answers of a minimum length are eligible