Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Similar to my question about easily spotted warning signs in code I think sometimes comments programmers make can tell you quite a lot (of not good things) about them in a short period of time. The scariest I've heard recently (from a senior) is:

I could use source control, but it'd slow me down

Also, although not in the same category when I see something listed at the top of someone's CV and I ask them about it:

Oh, I didn't really use that but I was just in the same room as people using it.

Duh! Then why is it featured prominently on your CV???

Finally I quite often interview people with what looks like an excellent set of skills on paper. Sometimes these are excellent developers, but some of them when asked about a topic will rattle through a dictionary definition like a machine gun (and probably a better definition than I would be able to say if put on the spot like that). Then when asked to explain even really, really simple things to do with that topic are totally unable to (usually coming up with something totally wrong, followed by a repeat of the dictionary definition). I suspect that these are developers who have been in teams where they're not treated well and so have had no opportunity to act independently - which results in their learning being very superficial.

What other things have you heard that tell you that a programmer is, er, let's try and think of a nice way of saying this...still taking the first steps towards being great?

share|improve this question

closed as not constructive by Mark Trapp Oct 25 '11 at 21:01

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

what's with the stereotyping of Indian programmers? There are 1.5 billion people on the subcontinent and the subset you've encountered is a statistically insignificant sample. The "Indian background" comment is so irrelevant as to distract from the point you were trying to make in that paragraph. Going to vote this question down for that reason. And no, I am not Indian. – les2 Oct 25 '10 at 1:00
It seems that I don't have enough rep. to vote down. Oh well ... – les2 Oct 25 '10 at 1:02
@LES2: I would downvote for you, but I'm not in the business of downvoting. I do agree that that part of the post is irrelevant, regardless of how Indian programmers may actually behave. – Jon Purdy Oct 25 '10 at 4:44
@FinnNk - I'm Indian, based in India, and I interview people for my team. I've come across the kind of person you're referring to, but they are not representative of Indian programmers as a whole. I do come across a larger number of such specimens than is normal, but I think that's because of the sheer number of people who work in the software industry in India. Sadly, quantity trumps over quality here. – talonx Oct 25 '10 at 8:08
Look - I guess you missed the part where I wrote "Often these are excellent developers". In fact they are often some of the best developers. However, in my experience (and from what other people in similar roles tell me), there are a minority who have been drilled in giving canned answers. Don't get me wrong I see equally bad (and worse) programmers from different backgrounds - just not in the same way that's all. And I fully accept that my experience in this area is limited - to make the text a bit clearer I'll remove the country reference. – FinnNk Oct 25 '10 at 8:16

41 Answers 41

Our build/install is just too complicated. It can't be automated.

I have walked onto way too many projects where the build, development setup, and/or the product installation "process" was a ton of manual operations.

The result was either a poorly documented process with one guy who knew all of the steps that had to be done (and would mess up at least one of the steps and be forced to do it several times, or worse not realize until later that it was done wrong), or a giant Word document with page after page of screenshots and instructions to type something at the command prompt and hit return, which made the process take forever, easy to skip steps, likely to be out-of-date, and just painful.

share|improve this answer
I had this at my last job. All they had to do was take the time and it could have been automated. – Terry Oct 25 '10 at 0:55
The Turing-Church thesis states that everything can be automated. A programmer who disagrees with the Turing-Church thesis should probably find another job! – Tom Anderson Oct 26 '10 at 16:36
@Tom that is only true if you believe everything is computable; this however is provably false. I agree that surely the build in question must have been though. – kasterma Oct 27 '10 at 13:18
@kasterma: If you can make the build without serious creative activity, you can automate it. If the build has rules about "when it gets into an infinite loop", well, there's more problems than the lack of automation. – David Thornley Oct 29 '10 at 15:01
If instructions can be written down, it can be automated. If instructions cannot be written down, you have a low bus factor on the project. – user1249 Jan 18 '11 at 20:07

Let's rebuild this from scratch.

share|improve this answer
Tentative +1, depends on the application. – Josh K Oct 25 '10 at 1:07
Actually if it was the code you wrote this might not be such a bad idea – Daniel Little Oct 25 '10 at 6:53
@Lavinski, yes, my code could definitely use a rewrite from scratch! Lot of cruft in there. But don't we always want to rewrite? – ScottE Oct 25 '10 at 12:16
Another tentative +1 Depends on 1. the application 2. who says it 3. what the plan is. If the new guy on the project instantly wants to rewrite; that's an alarm. If someone wants to re-write your Python app in Python, that's an alarm. Re-writing your legacy COBOL code in X (especially if you're down to one COBOL guy and have a team of X guys/gals) sounds like a good idea. Not "rewrite" in the sense of "drop everything and port" but in the sense of "no new COBOL development, transition features over piece by piece if possible, keep the old one running as long as we can". – Inaimathi Oct 25 '10 at 13:21
@ScottE - I was greatly amused by the line "One project I worked on actually had a data type called a FuckedString", thanks for that laugh! – Rachel Oct 25 '10 at 14:52

These four things were said to me by the same programmer:

  1. "I don't believe in encapsulation. There's really no point. All it does is add boilerplate and slows you down."
  2. "I don't do unit tests. That just slows me down."
  3. "Java is too slow. I need a fast language like C++."
  4. "I should really comment my code but it takes so long. It would just slow me down."

Mr. Speedy's code is a joy to be handed. Every time a piece winds up in my lap, it just slows me down...

share|improve this answer
Yea, +1 for #2... "We dont have time to write tests" – Fredrik Oct 25 '10 at 12:11
I hear #3 fairly regularly. Usually it's the age-old superstitious fear of garbage collection. Full disclosure, I don't do unit tests either, but that's more to do with my tools and my average project size. It has nothing to do with slowing me down. 1 and 4 still make me shudder though. – Inaimathi Oct 25 '10 at 13:25
Back up a couple decades, and my wife was asked why her code jumped around like that? The correct answer was top-down design and procedural programming, rather than writing everything in one big sequence. Apparently, that was too esoteric for that shop. – David Thornley Oct 29 '10 at 15:07
Yeah hear 'em all whats funny is if you heard 1,2,4 from the same programmer as 3. Because the first lot are supposedly slowing down their coding speed, but #3 will slow down their programming speed in order to speed up their program's speed. – Anonymous Type Oct 31 '10 at 21:32
#3 is true 100%, and stop finally arguing about it, gosh. It's the same as arguing that laws of physics don't apply to you. – Coder Mar 14 '12 at 5:36

"This is an emergency the change needs to go to production now, we don't have time for review, testing, or a roll-back plan."

share|improve this answer
This made me gasp. Geek campfire stories, eh? – Jon Purdy Oct 25 '10 at 4:45
It depends, but yeah mostly it's alarm bells. I used to work at a Java shop that pulled this kind of crap sometimes, and it always meant overtime for the other devs (I was the lowly front-end guy, so I rarely got pulled in for it). A PHP project did the same, except since their emergency deployment process was literally "copy the two/three offending files up", it was easily reversible and "Jimming" (I'll let you figure that one out) files onto the live server was more acceptable in these circumstances. It also very rarely caused overtime. – Inaimathi Oct 25 '10 at 13:14
@Anonymous Type: Because we don't stick to our guns and make everything follow the same process. We have to be better about educating them and showing them why the process is good so that they will internalize it and want to stick with it like we do. – Beth Whitezel Oct 29 '10 at 5:11
I once got into trouble that way. I was instructed to promote a certain change according to the standard process. As it happened, somebody had modified the production code without checking anything in, and without intentionally keeping a backup. Therefore, when I overwrote the production code as per SOP, I caused a problem and was blamed for it. I've rarely been as happy to leave a place. – David Thornley Oct 29 '10 at 15:05
@Anonymous Type - And because too many developers are happy to cut the same corners when it suits them. – Jon Hopkins Nov 18 '10 at 8:29

What sets off the bells for me is whenever I hear a programmer - a professional, not a student - asking a question that demonstrates that they really dont have a basic knowledge of computers or their profession. For example:

  • a web developer asking a question that clearly indicates they dont understand the difference between what runs on the server side and what runs on the client.
  • a programmer who does not understand that files names are not magical, and that a file's contents can be anything despite the name.
  • or my favorite, when I hear questions such as "Can [programming language] be used to create [some routine application]". Yes, thats kinda the point of a programming language.

I dealt with one guy not too long ago, and I kid you not, when I told him to just merge a couple of text files into a single file, he didnt know how to do such a thing. BIG RED FLAG right there.

I dont get particularly perturbed at 'religious' statements. If you want to use methodology X, or dont want to use Y, go nuts, you're an adult, I dont care what you do. But when I see programmers who obviously dont understand the very basics, it drives me nuts.

share|improve this answer
+1 for server and client side, this happens all the time! I do blame some of the frameworks for attempting the 'hide' the difference. .NET being one – billy.bob Oct 25 '10 at 9:24
@eddy556 I see your point about frameworks 'hiding' implementation. Even though I use many frameworks, I take the time to understand how they work. Same is true for many of my coworkers. – Arnold Zokas Oct 26 '10 at 15:29
Of course that is how it should be done. I've had so many times when I've been asked to find out why code after a Response.Redirect() isn't being executed its unbelievable – billy.bob Oct 26 '10 at 15:50
YES YES YES. TREBLE UPVOTE. Add things like Map m = SOME_CONSTANT; m.clear(); /* hey, why did that constant change? */. If you're making that kind of mistake, you don't even have the foundations to learn to be a competent programmer. – Tom Anderson Oct 26 '10 at 16:38
@billy.bob - Doesn't take an obfuscatory framework to confuse people about that. I once melted a guy's brain by showing him PHP that dynamically wrote JavaScript. – Dan Ray Aug 16 '11 at 16:21

"I'm not sure why it has to be this way, but it won't work unless it's like this."

While this can sometimes be a problem due to a problematic code base, this usually gets my alarm bells ringing, as it shows a lack of interest in finding out how the code really works and why it does what it does.

share|improve this answer
Oh yes, the classic "that code looks complex, did you write that?" "no, I got that code from googling" "so how does it work?" "I don't know" "do you understand it?" "no" "where did you get it from?" "I can't remember" conversation... – FinnNk Oct 25 '10 at 8:38
Seems you never maintained a big project someone else wrote. – back2dos Oct 25 '10 at 11:43
Sure I have, and I can see that it can be a problem. Most of the times it gets my alarm bells ringing. I've added a clarification. – Vetle Oct 25 '10 at 11:55
+1 because I have had to utter that phrase before... In my defense, I did dig through tons of code to try to figure out why... However the depth and complexity of the .net framework bested me. I will agree that this will set off alarms because it normally means the developer did not look into the problem deep enough to fully understand it. – Tony Oct 25 '10 at 12:34
That statement alone would bug me, but most of the times I've heard it it's been followed by some recognition that this isn't a Good Thing. – David Thornley Oct 25 '10 at 16:12

"It works on my machine."

share|improve this answer
A timeless classic! – FinnNk Oct 25 '10 at 14:51
...which is why I only ever put code into production that doesn't work on my machine :-) – Kramii Oct 26 '10 at 12:29
When I have to say that, I usually postfix it with "so I'll have more trouble figuring out what went wrong or testing". We had a nasty bug that cropped up only on Vista, and only on the users' machines. I wound up automating their workaround. – David Thornley Oct 29 '10 at 15:11
I think I used this one last month! – kirk.burleson Nov 9 '10 at 2:22
Last time I used this excuse was when my client wanted to test the program on his old laptop running a 4-year-old version of Mac OS X. I think it was justified on that occasion (since it worked on every machine in the world except his.) – finnw Jan 21 '11 at 23:06

“This is best practice.”

share|improve this answer
Sometimes it is! – Eric Oct 25 '10 at 16:53
@Eric: quite, but if so, it can’t be that hard to explain why, so that we can decide whether it’s applicable or not in this instance. – Paul D. Waite Oct 25 '10 at 17:03
Blind, unthinking application of cargo-cult best practices is DEFINITELY a red flag. – Dan Ray Oct 26 '10 at 12:19
@Dan: exactly. This phrase makes me worry that the developer in question isn’t really thinking about what they’re doing. It’s argument from authority, without even identifying a specific authority. – Paul D. Waite Oct 26 '10 at 12:40
@Eric, doesn't mean they shouldn't explain why it is. It's when they refuse to explain why that it's a process smell. – finnw Jan 21 '11 at 23:04

Personally, I look out for technically true statements that signal a broken understanding of software development/reality. Some of my favorites so far:

  • "I like developing in Joomla because it uses the MVC architecture" (the project in question is an application that will be deployed only on Windows Server and doesn't have any dynamic content)
  • "In my professional experience, version control never benefits the developers" (When asked, she clarified that she had only used Visual Source Safe in the past)
  • "Well what's the problem with using GPL licensed code? It's just open source, there's no big deal!" (maintained dismissive arrogance even after confronted with the facts of GNU GPL's restrictions, particularly ones that affect proprietary software)
  • "Why would you need to track those files? They're just scripts and code."

I'm lucky because my (non-technical) boss trusts me enough that when I call this particular developer out on something, I get the benefit of the doubt, but I know this kind of garbage must work at other companies, and I weep for them.

share|improve this answer

When a programmer fixes a bug which can't be tested (because it requires an extensive environment which only exists in production) and they say:

"Meh. I'll just check this in and assume it'll work."

Famous last words.

share|improve this answer
The appropriate response to this problem is to have a QA department with access to an accurate simulation of a production environment, and a requirement that every build be tested thoroughly by them before it ships. – Mason Wheeler Oct 24 '10 at 23:51
Please enlighten me. How can a developer make doubly sure that his/her fix is correct if he/she can't reproduce the bug? – Jim G. Oct 25 '10 at 0:14
@Jim: Sometimes the production environment is difficult or impossible to fully replicate. – Bobby Tables Oct 25 '10 at 0:36
Testing can only prove the presence of bugs - not their absence. -- Dijkstra – les2 Oct 25 '10 at 1:03
There's stuff I can't test, or can't test at all cheaply. (Working on code that will ultimately run on factory floor machines is like that sometimes.) What I really like then is code reviews. (Not that those catch everything, of course, but sometimes it's better to take a minimized risk.) – David Thornley Oct 25 '10 at 16:14

The user ir wrong!!, he/she doesn't have a clue, so I'll do what I KNOW is right. (disregarding user's needs)

share|improve this answer
They use normally doesn't know what they "need". However they do know what they want. Sometimes they are the same thing. Other times they are not. A good developer can figure this out. :) If we (collective we) made what the user wanted, there would be millions of facebook clones. – Tony Oct 25 '10 at 12:24
You are right Tony, what I meant was disregarding user needs (not "wants") and pretend the developer has a better understanding without validatind with the user. On the other hand, yo also have to consider what the user's boss has to say. – Miguel Veloso Oct 25 '10 at 17:19
The user is ALWAYS wrong. That's why you have to reproduce even if they give you the exact steps for testing. – Anonymous Type Oct 28 '10 at 22:52
@Tony I disagree, clients or users sometimes (often?) do not know what they want, either. – Mark C Nov 6 '10 at 17:37

"I solved the problem by increasing the request timeout to 1 hour"

share|improve this answer
This may or may not be a bad thing, depending on the complexity of the request. I've seen issues where this was the correct fix. I've also seen long-running queries where the correct fix was to optimize the SQL or fix the DB table indexing. It all depends on your situation. – Mason Wheeler Oct 29 '10 at 22:13
Ah, the halting problem :) – user1249 Jan 18 '11 at 20:15

My favorite 'Don't walk away. RUN' red flag comment:

"I don't see a problem with a 700 line method."

(usually an event handler where every possible event that can be raised on a window is funneled into a single event handler where the first thing it does is to do a switch on the control that the event originated on. Why have separate event handlers? Those would just clutter up the code!)

share|improve this answer
This looks like a good time to drop a link to It Really Happened: Legacy Programmer Tales. – Mark C Nov 6 '10 at 17:24

Q: "So what is this library about ?"
A: "This library is a DSL"

You can replace this by : "What is this class about ?" -> "It is a Command pattern"

This rings a bell because this developer is more interested in how the code is written than on what it does and what is its final goal.

How can you be good programmer if you put more value on the "beauty of the code" than on client value ?

Note that I don't say that design patterns are useless or that code quality is useless. I just say that what comes first is understanding and meeting customer needs.

share|improve this answer
We've got a few guys like that on one of our teams. They are very smart guys; when they focus on getting things done, they're truly wonderful. But they are prone to wandering off on flights of creative genius that turn the codebase into some kind of mad Ballardian sculpture park full of incomprehensible, useless, beauty. – Tom Anderson Oct 26 '10 at 16:45
And to quote Steve Jobs, "real artists ship". – Tom Anderson Oct 26 '10 at 16:47
dang it! That's me! Well, thats what I'd be like naturally anyways. – Winston Ewert Oct 30 '10 at 1:19
Tom - beautifully put! – quickly_now Oct 30 '10 at 3:46
@Tom Anderson - you are talking about "Architect Astronauts" ( – Joris Timmermans Sep 12 '11 at 14:48

"I'm sure I can fix the bug, I just need to try a few more combinations of..." sets my alarm bells ringing as an indicator of a programmer who's approach to fixing an identified bug is simply to guess, and to shuffle parameters or constants (or even code) randomly in the hope of stumbling on a fix. This is particularly dangerous when some superficial improvements may initially be obtained, and the developer presses on assuming that with enough time to continue prodding at the system the fix may be arrived at by chance or intuition. Needless to say, this is absolutely no substitute for a deep understanding of the code and the problem domain, and a more structured analysis of what's going on.

share|improve this answer
Not entirely sure of this one... sometimes we're dealt with a black box/dll that has no sourcecode. Or perhaps this is unit-testing articulated the wrong way. Programmers aren't always the best at explaining things. (otherwise I agree with you) – LamonteCristo Oct 25 '10 at 14:29
Good point. I was thinking of cases where the code is available and actively being developed. If programmers are treating such code as a black box... something's wrong somewhere! – timday Oct 25 '10 at 19:34
Even if you have the source, this can be a productive approach - to debugging. But once you've found some pairs of inputs that get interestingly different behaviour, you can follow the code downriver to the point where the flows of execution diverge, and then you start hunting around for the bug. Of itself, as you say, it's not a fixing technique. – Tom Anderson Oct 26 '10 at 16:42
OK I concede there are always exceptions to the rule; that's why I list this as an "alarm bell" (rather than "this must never happen"). It's a signal that I need to understand what the developer is doing/trying to do better and form some opinion of whether what they're doing is worthwhile and productive, or whether they need some help. – timday Oct 27 '10 at 13:44

I don't need to write unit tests as I write bug-free code

share|improve this answer
I had somebody like that. Oh boy. What an adventure that bug-free code was. – quickly_now Oct 30 '10 at 3:49
and I've been a tester for one. Ugh. – StevenV Aug 16 '11 at 17:00

"It's impossible to test this"

Seriously, I managed a whole team who believed this. Fortunately it didn't take long to convince them otherwise.

share|improve this answer
On some very embedded systems, this can be close to true. Things can be very difficult, time consuming or expensive to test. Usually that means - try and test a different way, or even (shudder) test as part of a larger accumulation of units rather than at the single unit level. There's always a creative way to test. – quickly_now Oct 30 '10 at 3:47
It was a web app! – Henry Oct 31 '10 at 7:44

When asking another developer to do something:

It's not that hard.
Can't you just...

All too often a developer wants someone on another team to make a change. Dev A doesn't understand how to do it, so he asks Dev B to do it instead. Since it's no longer Dev A's problem, it must be simple right? Sometimes it's not as simple as Dev B likes to believe (and there may be good reasons why it doesn't already do things that way), but he doesn't care because someone else has to do it.

When you don't work in a particular field or on a particular project, it looks very simple from the outside. If I write a client for another developer's server, it looks simple to me - that's how things should be and it's a sign the server's well-written. But I know it's probably not that simple underneath and if I want a change to be done, and the developer comes back and says no, I don't turn around and say "come on, it's not that hard - can't you just do X?" because I know that the developer probably isn't an idiot, knows his own app better than I do, and has already thought of X and dismissed it.

share|improve this answer

We'll fix it in the next version.

share|improve this answer
I've got five year old "we should do this in 2.0" comments in the codebase I inherited. – Tim Williscroft Oct 26 '10 at 0:13

"And then I do this, 'just in case'."

You mean... you don't know what your code does? You don't know whether what you want to do would have worked or not had you not done that thing, just in case?

share|improve this answer
that is smart programming, recently I saw example of that. Some WebService should never return null, so app threw nullpointer when it did. in next version it checks for null. – IAdapter Oct 26 '10 at 15:08
I'm more on about the hitting-buttons-on-the-ui stuff. You know, like how people hit apply before hitting ok 'just in case'. When a developer does that for his or her own code, alarm bells ring. – Kaz Dragon Oct 26 '10 at 15:34
I saw an example of this once when someone was catching the exception thrown by passing in an invalid regex expression to a framework class...except in this case the regex was hardcoded (in the actual method call). Good exception handling is important - but too much can indicate that the programmer doesn't understand what's going on (or hasn't thought it through). – FinnNk Oct 30 '10 at 9:35
One exception: Just in case is good when adding asserts to your code, just to be sure you really know what your code does. – dsimcha Nov 6 '10 at 21:47
I call this "rubber chicken" programming e.g. Oh, that? We shake the rubber chicken at the build server every Tuesday morning, it tends to crash otherwise. Wait! Why are you running away? – Binary Worrier Aug 12 '11 at 12:55

People that want to apply rules without seeing the context.

I know best practices are really good but they are not magical things and you have to know when and how to apply them. Someone who tell me to apply a rules without seeing the context just tell me they don't know what they are doing.

If you want more info on this I suggest to read about the Dreyfus model of competence. Basically they done study to find what differentiate novice from expert and found that the more you go up on the ladder the less you have to blindly apply rules: you know why they are usefull, and, as such, when to apply them and when not to.

This is a key point from the study: context is everything.

share|improve this answer

It just works.

Anytime I hear this phrase, I just assume whatever is suppose to just work doesn't. I learned early on that if someone can not explain in detail how code (or anything for that matter) is going to work, it probably doesn't.

share|improve this answer
I've had code that "just worked" before, without me being able to understand how it could be. That's scary. – David Thornley Oct 25 '10 at 16:16
I mentally translate that to, "It worked the last time I checked, it's fragile, and the guy who understands why it still works left the company 6 months ago." Bad times. – Alex Feinman Oct 25 '10 at 17:00

I think we need to use XML...

You don't hear this one so much now. But there was a period some years ago when every developer seemed to want to do something, anything with XML (probably just to tick it on their resume). Result was a bunch of systems with hideously verbose, overcomplicated configuration files, ghastly persistence systems, insane communication protocols and incomprehensible excuses for DSLs, despite the most obvious rational design invariably being a simple flat text file.

share|improve this answer
  • "This thing surely works" / "This module has no bugs" (about his code)
  • "I've almost done, this already compiles"
  • using the wrong terminology in comments/variable names/function names (and really abusing it)
share|improve this answer
"I'm almost done, this already compiles" - a classic! In fact, any kind of "I'm almost done" is suspect, given that the last 10% often takes 90% of the time. – Tom Anderson Oct 26 '10 at 16:49

Here are a few fun ones I've heard...

QA is reporting too many bugs against us, so we don't have time to fix the compiler warnings.

At a company where the technical management wasn't really paying attention:

I know the way I've set up the company's source control system only really works well for me, and works like crap for everybody else, but you'll just have to live with that.

A development lead for a Linux-based product that was dead in the water without snazzy graphics, WebKit, a PDF engine, and highly sophisticated Javascript, all of which lives outside the kernel:

That's all user-space code, so it's all the same, and why should we care about it anyway?

share|improve this answer
Wait, people fix compiler warnings? :) – Tony Oct 25 '10 at 12:31
@Tony: Of course! What did you think @SuppressWarnings was for? – Tom Anderson Oct 26 '10 at 16:48
  • "Didn't have time for this, fix later" : Usually means it will never work.
  • "This is hacky code but it works, based on xyz" : Usually means I stole this code and I have no idea how it really works.
share|improve this answer

"Yeah, it's fixed. I added a scheduled task to reboot the server every night at 2 am."

... or any other "fix" that just masks the problem instead of actually solving it.

share|improve this answer
Sometimes you just need it working, not right. – CaffGeek Aug 16 '11 at 15:50

All our data is safe since we are using C++ which (unlike C) will automatically take care of all data hiding and abstraction.

share|improve this answer

"Let's get this code written first; I'll get to the tests later."

share|improve this answer
-1. TDD isn't the only right way to write code. – dsimcha Nov 6 '10 at 21:51
Who said I was talking about TDD? – Eric King Nov 7 '10 at 3:48

Due to time pressure we did not write any tests.

share|improve this answer
"There's never time to do it right, and always time to do it over." – David Thornley Oct 25 '10 at 16:17
Or you cram the tests in a week before "go live". – kirk.burleson Nov 9 '10 at 2:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.