Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have many great tools which helps a lot when programming, such as good programmers text editors, IDEs, debuggers, version control systems etc. Some of the tools are more or less "must have" tools for getting the job done (e.g. compilers).

There are still always tools which do help a lot, but still don't get so much attention, for various reasons, for instance, when they were released, they were ahead of their time and now are more or less forgotten.

What type of programming tool do you think is the most underestimated one? Motivate your answer.

share

locked by Thomas Owens Aug 30 '13 at 9:22

This question's answer is a collaborative effort: if you see something that can be improved, just edit to improve it! No additional answers can be added here

closed as not constructive by ChrisF Nov 11 '11 at 9:51

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.

3  
Our brains? - - –  Trufa Mar 12 '11 at 1:55

32 Answers 32

up vote 69 down vote accepted

A rubber duck. Yes, really.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Rubber duck debugging, rubber ducking, and the rubber duckie test are informal terms used in software engineering to refer to a method of debugging code. The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

To use this process, a programmer explains code to an inanimate object, such as a rubber duck, with the expectation that upon reaching a piece of incorrect code and trying to explain it, the programmer will notice the error. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent...

share
5  
I do this all the time with my husband. As a tech support guy with just a smattering of programming ability, he understands about 60% of what I say but forces me to explain the 40% that I don't understand as well. The number of occasions where it works is really quite impressive. –  Ethel Evans Mar 11 '11 at 19:32
1  
You laugh. I had a coworker actually have a rubber duck on her desk. –  Berin Loritsch Mar 11 '11 at 20:51
55  
I tried it, but my rubber duck couldn't seem to focus on the problem. Where can I find a properly qualified rubber duck with a genuine interest in programming? –  Steve314 Mar 11 '11 at 21:25
9  
@Steve314 You should go for one of these: flickr.com/photos/texhex/4837563061 –  Andreas Johansson Mar 12 '11 at 16:04
3  
I use my journal for this. I sometimes have quite lengthy discussions with myself on it. I wish I could make myself understand what I mean, sometimes. Writing this into a journal sometimes helps a lot later on, when I wonder what the idiot who wrote the code I'm working on was thinking. –  Lars Wirzenius Mar 12 '11 at 16:59

Pen and notebook.

  1. Works without electricity.
  2. Portable.
  3. Doodle on/in when bored in meetings
  4. Store useful information.
  5. If it is written down, people attach more importance to it.
  6. Others can read it and learn.
share
3  
The Russians used a pencil. –  Job Mar 11 '11 at 22:03
1  
@Job: …and vodka! –  Spoike May 4 '11 at 10:43

Diff tools seem to be underused when comparing log outputs or data in flat text files. Or maybe that's just a niche? I seem to find it very useful and helpful for debugging to compare huge logs of program executions and pinpoint one or two details that changed.

Performance profiling tools are also very good to have, especially when you hit a critical bottelneck, but it seems very few people are familiar with them (and I admit myself to a degree in this category).

Good XML tools are vital - if you're working with XML files more than a dozen lines or multiples schemas. Sometimes you need more than just basic syntax highlighting other editors provide. Also when working with XML, learning XSL can be very useful. Many times I see what could be done in a simple XSL transform done in many lines in the application's code. Though to clarify: I am not suggesting that XML itself is an "underestimated programming tool"; I am suggesting that the value of good XML editors is underestimated, from what I've seen.

share
1  
++ Absolutely diff is underappreciated. On the subject of profiling, you're not alone in thinking they must be useful, but you yourself don't know how. Check this. –  Mike Dunlavey Mar 11 '11 at 19:02
23  
+1 for profiling, +1 for diff tools, -1 for XML tools. Some people, when presented with a problem, think "I know, I'll use XML." <Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening> –  Mason Wheeler Mar 11 '11 at 19:06
2  
@Mason: Cute XML. –  Mike Dunlavey Mar 11 '11 at 19:35
10  
@Mason Wheeler: I didn't suggest XML as a tool to solve problems, I suggested Good XML Tools - when you have to work with XML, make sure you have an editor/tool that is very good at it. Something that can execute Xpath queries, schema validation, transformation, value vs. structure comparison (a special kind of diff tool I guess) etc... Simple editors with highlighting just can't cut it when things get messy - they often make things worse (btw I like your XML code ;) ). –  FrustratedWithFormsDesigner Mar 11 '11 at 19:41

Regular Expressions

They are just so useful. They help when searching through log files, parsing text etc.. They are just extremely useful.

I find it strange how many people I know that don't ever use them because there is a bit of a learning curve associated with them. A lot of times I see people do things the hard way (Note: before regex I did things the hard way) when a simple regex could get it down quickly.

share
8  
Remember that Regular Expressions aren't a Swiss army knife even if they are great when applied correctly. –  Anto Mar 11 '11 at 19:22
10  
Extremely useful - but often abused, leading to cryptic unmaintainable code. The old "now you have two problems" saying does have some basis in reality. –  Steve314 Mar 11 '11 at 21:32
4  
RegExes are a Swiss army knife: An adequate tool for lots of quick jobs, though probably not the right tool for building an entire house. –  JasonTrue Mar 12 '11 at 5:07
3  
Hmm, for some reason I always got the impression regex was far from being underestimated. Too often I see people reaching for a regex where a simple split/for-loop would suffice or when regexes are simply not the answer (e.g. parsing xml/html). –  MAK Mar 12 '11 at 18:41

Your teammates. When you are off on some hot-shot idea and forget to incorporate your team, you'll never hear their concerns or ideas for why it won't work or for why it could be even better.

I say this, because it's easy to think that programming is some antisocial thing people do off in corners with their brilliant ideas. People who think this underestimate the value of teams and their teammates in helping make ideas/projects sink/swim.

share

Google. There is are very few problems that haven't already been solved and documented. A well-tuned Google query can save everyone a lot of time.

share
13  
A good tool but I'm not sure I'd call it underestimated, at least not anymore (maybe I would have agreed 9 or 10 years ago). –  FrustratedWithFormsDesigner Mar 11 '11 at 18:52
12  
I'm sorry, but Google underestimated? At the very least Google is overestimated :) –  eestein Mar 11 '11 at 18:58
2  
I know, I know! But my rationale for saying that it is underestimated is one that I suspect you will agree with: at least 75% of the questions that are asked on StackOverflow are easily answerable with Google, yes? Clearly, it is to some degree underestimated if that many people are not using it. If my rationale is flawed, I will delete my answer. –  Adam Crossland Mar 11 '11 at 19:06
3  
@Adam Crossland: 75% is being kind. I think it's higher than that. –  S.Lott Mar 11 '11 at 19:26
1  
@adam @s.lott so I guess the point is that Google is not used properly. With that I agree. So many questions could be answered (wouldn't need to be asked) if people knew how to Google properly. Regards. –  eestein Mar 11 '11 at 19:56

Far and away the most underappreciated tool for finding "bottlenecks" is Ctrl + C or the "Pause" button, in a debugger.

Check the last paragraph of this post, and this post, and this post, for starters.

So many times I see/hear of people saying "The program's too slow! What can I do about it? I tried a profiler (if they did), but I don't understand what it says. Anybody got any guesses? Help!" Well, guesses are just that. What I've always done, and others have too, is get it going, interrupt it, and examine the call stack. If the problem is really bad, bingo, it's right in front of you. If the problem is only mild, you do it several times. Anything that shows up on more than one sample, that you can avoid, is a bottleneck you can fix.

Yeah, this is downvote-bait, but it works.

share

What type of programming tool do you think is the most underestimated one? Motivate your answer.

The compiler.

Most people don't take time to understand what their compiler of choice does. They just feel that it makes the code into a runnable program and that is as far as they go. On most modern ones, there are several configurations that you can feed into it make it do what you need it to. Here's an example, I bet half the devs in your office have no idea how to set the warning as errors level (assuming it actually has one). What options to do you have to output debug symbols? Which optimizations (or what level of) do you want it to make. The list goes on.

share
3  
@Kevin: and I would add ways to write code to actually have the compiler perform checks for you (for statically typed languages). Most devs use off the shelf types (such as string) to represent any kind of info, where they could define simple but incompatible types for unrelated data... and have the compiler they didn't mess up when passing arguments. –  Matthieu M. Mar 11 '11 at 19:23
3  
Every compiler warning is a precious gift. Don't ignore them! Ask for more! -Werror should be mandatory. –  Kristof Provost Mar 11 '11 at 20:18

Your brain. Other tools wouldn't have much meaning without it.

share
4  
I have rendered mine mostly unserviceable on occasion. –  David Thornley Mar 11 '11 at 18:43
3  
"more or less forgotten" :-S –  user1249 Mar 11 '11 at 18:44
5  
I would say it's underestimated. Too many people are always looking for shortcuts so that they don't need to think. There is no replacement for common sense and logic, and tools just cannot replace that. –  jnevelson Mar 11 '11 at 18:52
2  
I agree with Jonathan, the brain is often underestimated. In fact too many programmers rely on the few tricks they know instead of stepping outside the box and occasionally writing a bespoke (cheap and dirty, throw away class) test case and test tool to investigate the problem at hand. I have on many occasions given developpers the means to go beyond their state of thinking and solve their problems with not much more than a few questions. –  asoundmove Mar 11 '11 at 19:19
1  
Some comments got me to change my opinion, +1 :) –  Anto Mar 11 '11 at 19:25

Good old:

print

Sometimes a debugger or profiler or a UML flow diagram is useful. And sometimes they make you crazy. I always find myself falling back on using print statements (or trace or NSLog or what-have-you) just to make sure my code is doing what I think it's doing when I think it's doing it.

share

Plain old scripts... no matter how many next generation languages we develop we still heavily rely on scripts also most of the day to day tasks can be achieved by writing a few line of scripts.

share
1  
See.. I would disagree with this one. Yes, scripts can automate some tasks. But often they're taken far beyond the point of sense to the point where they just become a big pike of spaghetti. –  Billy ONeal Mar 12 '11 at 16:49
1  
True , big scripts are gruesome to look at and one might use perl or python for it. Though they are still great at getting small jobs done. –  Gaurav Sehgal Mar 13 '11 at 2:55

Pen and whiteboard.

You can't beat low tech when trying to explain something.

share
3  
Duplicate answer - programmers.stackexchange.com/questions/57148/… –  ChrisF Mar 11 '11 at 22:06

Perl and other scripting languages. Great for tasks that are just a bit too complicated for GUI tools like Agent Ransack.

share
1  
I'm not sure they are underestimated... –  Anto Mar 11 '11 at 21:33
3  
Definitely underestimated ... expecially Perl. It is a lang. very well designed with the keep things simple motto ... as such, it's priceless for quick tasks which just need to get done. –  Rook Mar 12 '11 at 3:08

ack. It's like grep -r, but it's designed for seaching through your source code.

share

Keyboard shortcuts that allow quick, frequent and safe refactoring. Learning how to extract (or inline etc) variables, methods, constants, or classes at the press of some keys fundamentally changed how I code. You will only refactor frequently (i.e. enough) when the cost is minimal, so making these shortcuts second nature is essential to writing and maintaining good code as far as I'm concerned.

So generally, use good tools (IDE/editor) and learn how to get the most of the features they provide.

Unit testing and TDD comes next, to keep your code testable and prevent fear of refactoring.

Use these and you'll easily move towards writing correct maintainable code that conforms to the DRY principle and is self documenting.

share

Unit testing offers the following benefits:

  • Developers become the first clients of the code. The quicker a bug is caught, the less expensive it is to fix. Bugs may be caught before a build, install, or deployment.
  • Testing changes your perspective on the code. Is the design clear? Does it handle corner cases?
  • The Hawthorne Effect will improve quality, simply by announcing that a team is publishing quality/testing metrics.
  • Even if tests aren't checked into source control, they can be a great way to explore and learn new terrain.
  • A high probability of fewer bugs!
share

Code generators

Code generators can create a large amount of efficient and bug-free code from a simple definition. ORM type uses are the most obvious for creating data access classes, but there's many more potential uses.

Code generating support seems to still be in its infancy both from a programmer and framework point of view, but I believe it's something we'll see more and more of. In .NET you can start dabbling with the CodeDOM stuff.

share

I use AgentRansack heavily. It is a tremendous help searching through thousands of files very quickly. It has saved me so much time, but I don't know of a lot of programmers that know about or use it.

share

Formal Methods.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

It's hard to overstate their importance. Every loop and every if statement starts out as an idea that requires some kind of "proof". Most programmers do this proof most of the time in their heads. You ask what the if statement does and they can articulate -- soundly and logically -- what the choices are and why the choices are complete, consistent, and exclusive.

But some just seem to guess randomly. They need more help and formal methods could be the kind of help they need.

It's just algebra (and calculus) for code. Nothing too complex or sophisticated.

share

Physical design patterns like leaving the chair for a quick jog in the sunlight and fresh air keep our brains running at peak awesomeness.

share

Well it's Half Life 2 (insert your favourite game here). If i got a problem I can't solve I just quit and start playing with my favourite game and suddenly the solution pops in my mind. So to be honest it is not a game or something like that but doing something else. I often see people sitting on a problem for hours without solving it and all they should do is putting their brain offline for a short period.

share

Stack Overflow - quick expert help when you are stuck

question and answer site for professional and enthusiast programmers. It's built and run by you as part of the Stack Exchange network of Q&A sites. With your help, we're working together to build a library of detailed answers to every question about programming...

share
4  
maybe even overestimated, or at least overused –  Anto Mar 12 '11 at 21:19

I think it is Notepad/TextPad/simple text edit programs. Everyone has a time when they need a quick fix that does not require opening an IDE and need just a quick edit. And all computers have some kind of simple text editing program.

share

Asserts and a good alwaysAssert() function. IMHO these are more important than unit tests, because unit tests can only find bugs in the specific cases you thought to test. If the same programmer writes the code and the tests, he/she will probably miss the same edge cases in both. Furthermore, sometimes unit testing is impractical because the environment in which the component functions and/or the data it operates on is too complicated to come up with a contrived test case for.

The beauty of asserts lies in their ability to document assumptions and test them on non-contrived inputs. If any of these assumptions are wrong, your code fails loudly instead of "working" but producing subtly incorrect results. It also fails closer to the root of the problem than it would without the asserts. In practice, if you explicitly state enough assumptions about a piece of code and all of these assumptions are correct then the code is usually correct.

One common gripe about asserts is that they can be turned off. IMHO every language or standard library should have an alwaysAssert() function or rough equivalent that does the same thing as assert but can't be turned off. This can be used for checking assumptions in non-performance critical areas of code, where the benefits of turning off asserts are negligible.

share

The F1 key. - Useful for programs you don't know and for programs you are working on. (Assuming that it's a large application.)

Powerful to filter out issues were a users report bugs based on their interpretation of how the software should work. Of course, it could be that the design itself was flawed. But that's another story.

share
2  
Both underestimated and also underimplemented. –  Anonymous Type Mar 12 '11 at 4:45

Various UNIX core utilities, but primarily find and occasionally grep or ed. The ability to find things in deep nests of files is invaluable, particularly when you suddenly inherit a codebase and have to fix it. Even if said code is well-documented, you will probably have to hunt, and a strong understanding of find kills it.

share

Curiosity

Call it the "Riddle of programming." What is a tool compared to the person that wields it? The desire to know how and why something does or does not work expands one's knowledge more than any specific tool and that is true beyond programming.

share
Ctrl + C    
Ctrl + V

Saved countless hours worldwide!

share

Tail

Tail can be used to monitor program log output file in realtime. It has been of great help when developing for systems that doesn't provide others means of reading the log.

Example programs are;

share

I kludged together a Perl call graph generator once. It was extremely useful, but fell over hard on non-procedural code or out-of-file routines.

share

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