Disclaimer: This post maybe have no basis in reality at all outside my team, it's just a question. This post is done with information on a case study of 1.
I moved to the wide world of ANSI C++ after working in C# with the love of ReSharper for the better part of 2 years. I managed but I definitely felt the absence of the great refactoring tool that took the things that should be easy and trivial and made them so. C++ is not that way, especially with old IDEs. So I started searching this past weekend for a C++ refactoring tool that actually supported my IDE. I found one that claimed to support it, Visual Assist X, so I installed it and started playing around with it. It works pretty well for what I need it to do but I haven't fully explored it yet.
Either way, this post isn't about Visual Assist X. Today after I set up my keyboard shortcuts (to match ReSharper, no less) I called my team's senior developer over and showed him what it could do.
Him: Another tool?!? *shakes head* I don't trust tools to do much of anything. They're just more systems with their own bugs.Me: Yes but what they do they do well. Why not take it for what it is and accept that nothing is perfect?
Notice these are not direct quotes. I remember better what he said than my own response (mostly because I was surprised by his reaction), but that was the general nature of the conversation. He then proceeded to call me "Mr. Tool" and was quick to dismiss it. I was a bit confused by this, but didn't think much of it at the time. I had work to do so I went on my way.
Now, sitting in my living room catching up on back episodes of Legend of the Seeker something creeps up from the back of my mind. Do I really rely on that many tools? Let's list them out:
Development:
Development:
- Visual Studio
- CppUnit (is that really a "tool"?)
- Rational PureCoverage for capturing code coverage
- Hudson for Continuous Integration
- CppDepend, CCCC, CppCheck, SourceMonitor for various static analysis (some do things better/more simply than others)
- And now Visual Assist X for refactoring support.
- Jira + GreenHopper
- Confluence
- Crucible
- Fisheye
I don't think this list is unreasonable at all. OK, so maybe the static analysis tools are a bit excessive but I like data, especially when it costs me next to nothing to get it through Continuous Integration.
Let's look back to September 2008 when I joined the team. They were using exactly ONE of these tools, Visual Studio. No unit testing, no continuous integration, no process support tools, certainly no automated testing, and worst of all no feedback mechanisms of any kind until a project ended and you handed it over to the customer to say "I hope this is what you wanted".
Flash to today. We have 20+ configurations in Hudson, our latest project has 90%+ unit test coverage at all times, our system testing is as automated as it can be so our test team isn't overwhelmed, all our documentation is maintained in Confluence, and all our issues and tasks are tracked in Jira.
I feel like each of the tools listed above plays an integral part in my day-to-day work as a developer. Obviously as developers we spend less time in the management systems and use very limited features of them, but does that make them any less important? No. If management can just jump out to Jira to check our status or out to Confluence to answer their question, that's one less thing they had to bother me or my team about. It makes me happy and I don't even know it, and I'm sure they appreciate it too.
Now I finally get to the question. Is the reason for his reaction a generational thing or am I completely off base? Are the youth more likely to find a tool-based solution to a pain point while the more seasoned have just learned to deal with it?
Then there's the other possibility, am I over-reliant on tools? Maybe I could simplify, but do I understand how they work, their purpose? Absolutely. I know what the scope of their functionality is, how they do what they do, what they're NOT meant to do, and how to bend them to my will within the constraints of the tool. Each one of them adds value and there are only 3 of them that any developer on the team really has to know or use; Visual Studio, CppUnit, and PureCoverage...I take that back, PureCoverage isn't necessary for them to understand, they just need to have it installed since every time they run a build it runs the unit tests with coverage. They could completely ignore the results and I wouldn't know the difference.
What do you think? I'm sure there are exceptions as there are with any rule, but are the youth more likely to blaze new trails?
Let's look back to September 2008 when I joined the team. They were using exactly ONE of these tools, Visual Studio. No unit testing, no continuous integration, no process support tools, certainly no automated testing, and worst of all no feedback mechanisms of any kind until a project ended and you handed it over to the customer to say "I hope this is what you wanted".
Flash to today. We have 20+ configurations in Hudson, our latest project has 90%+ unit test coverage at all times, our system testing is as automated as it can be so our test team isn't overwhelmed, all our documentation is maintained in Confluence, and all our issues and tasks are tracked in Jira.
I feel like each of the tools listed above plays an integral part in my day-to-day work as a developer. Obviously as developers we spend less time in the management systems and use very limited features of them, but does that make them any less important? No. If management can just jump out to Jira to check our status or out to Confluence to answer their question, that's one less thing they had to bother me or my team about. It makes me happy and I don't even know it, and I'm sure they appreciate it too.
Now I finally get to the question. Is the reason for his reaction a generational thing or am I completely off base? Are the youth more likely to find a tool-based solution to a pain point while the more seasoned have just learned to deal with it?
Then there's the other possibility, am I over-reliant on tools? Maybe I could simplify, but do I understand how they work, their purpose? Absolutely. I know what the scope of their functionality is, how they do what they do, what they're NOT meant to do, and how to bend them to my will within the constraints of the tool. Each one of them adds value and there are only 3 of them that any developer on the team really has to know or use; Visual Studio, CppUnit, and PureCoverage...I take that back, PureCoverage isn't necessary for them to understand, they just need to have it installed since every time they run a build it runs the unit tests with coverage. They could completely ignore the results and I wouldn't know the difference.
What do you think? I'm sure there are exceptions as there are with any rule, but are the youth more likely to blaze new trails?
I agree there is much skepticism towards tools.
ReplyDeleteI think it is natural. If you have a good idea and you tell it to a group of people then they will always be skeptic at first. They will be skeptic even if you say: "this tool will automate 2/3rds of your work so with it your salary can be increased with 200%."
I develop a tool called Cppcheck. I see much skepticism towards analysis tools.
If Cppcheck finds a serious bug, this bug can sometimes be ignored/rejected because it is found by a tool. A common response is that Cppcheck is just a tool. It isn't clever. Therefore its results are redundant.
I agree that Cppcheck is a tool and that it isn't clever. :-)
Another common response is that you can't use a battery of tools to solve a problem - you must choose 1 tool. I think it's some kind of natural response because I sometimes see no logic reasons:
* It isn't economy. Because if a commercial tool is used at a company then they don't want to use free tools to complement that.
* It could be that it's harder to learn multiple tools. But it doesn't seem to matter if the tools are simple to use.
Thanks for your comment. I agree that it *shouldn't* matter if the tools are simple to use, especially the static analysis tools. Developers don't run them on their own machines anyway, that's Hudson's job. The only static analysis tool I run locally is CppDepend and that's just because that tool really does have a steep learning curve.
ReplyDeleteI will also say that you need to have a good reason for using a tool. We don't not do code reviews because we run static analysis tools, but if you write crappy code with memory leaks everywhere in the hopes that your plethora of static analysis tools will find it, you don't deserve to use the tool in the first place.
Tools are not substitutes for knowledge and understanding. As a tool developer yourself, you know probably better than most what it takes to REALLY perform code review checks for memory leaks and the other things CppCheck does. Understanding should always come before automation, even if you're not the one who wrote the tool.