Life, Teams, and Software Engineering

Category: refactoring

Is tooling only for the youth?

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:

  1. Visual Studio
  2. CppUnit (is that really a “tool”?)
  3. Rational PureCoverage for capturing code coverage
  4. Hudson for Continuous Integration
  5. CppDepend, CCCC, CppCheck, SourceMonitor for various static analysis (some do things better/more simply than others)
  6. And now Visual Assist X for refactoring support.

Process:

  1. Jira + GreenHopper
  2. Confluence
  3. Crucible
  4. 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?

    An Adventure in Refactoring Part 1

    In this N-Part series I’m going to chronicle the refactoring efforts of my team and I on my current project and pose some questions that fall in the realm of DDD, refactoring, testing, etc. I don’t really have a road map for this series but here is a basic idea of what I’m planning on hitting:

    • Part 1 – Project History & Overall Goals
    • Part 2 – Finding Focus – Refactoring, Where To Start?
    • Part 3 – The Big Picture – Utilizing Visualization Tools to Target Refactoring and Find Patterns
    • Part 4 – A Flood of Information – What is NDepend Trying to Tell Me?

    Lately on my project there have been a lot of good things happening. TeamCity has been brought in for Continuous Integration, NUnit has begun to be used for automated regression testing (paired with WatiN for web testing), Sandcastle has been implemented at build time (nightly) to keep up to date project documentation, and I’ve been trying to sell NDepend as a refactoring/inspection tool the more I learn how to use it, and more importantly, understand what it’s trying to tell me.

    Background

    Before you can really understand where I’m trying to go and what it’s going to take to get there you need some background on where this application came from and what its current state is. The project was initiated more than a decade ago by a group of people who knew how to program, but really weren’t developers. It was originally written in ColdFusion and was later ported to VB.NET when the need for a newer technology presented itself. This was a great first step and is necessary for any long term project to survive and continue evolving.

    The problem was that while the application now existed in a new object oriented language, the scripting mentality came along for the ride. Therefore a solid object model was not developed at the time of the port and over time any architectural changes that were meant to be enforced fell by the wayside when a release drew near. Since software is simply a means to an end within our organization (software is not our core business) best practices are sometimes not in place or, if they are in place they’re not the highest priority.

    Flash to today and the team is populated with people who know software. Even the PM has a background in software, specifically with this project. I’ve been fortunate in the short time I’ve been here to be placed with a group of open-minded people who are willing to see both sides of an argument and accept (and follow) a path to positive change for both process and design. I’ve heard horror stories about people being set in their ways and resisting change, even when the benefits are obvious.

    The story I’ve heard over and over again is “we’re aware of the design problems with that [class], [assembly], [subsystem], etc. but we just haven’t found the time to get in and change it.” I imagine that this is a problem in the majority of projects out there that ship a product in iterations (and probably some that don’t). You promise X at the beginning of an iteration, implement it during the iteration and then ship out at the end with little to no slack time.

    This is all well and good if your definition of ‘Done’ is implemented, tested and refactored because your estimates will have taken these things into account. However, if your estimates don’t include testing and refactoring more than likely you will exhaust your estimate and run out of time. This is the first thing that has to change when attempting to implement these changes with a group who has never worked with them before. Their definition of ‘Done’ needs to change, otherwise we’ll never have the time to really test and refactor.

    Ok, I’m going to stop right there. In all fairness, we did/do have QA on our team and our iterations end with a two week system testing buffer, but this testing effort was purely at the system acceptance level. There was no developer testing going on at all, so even when a problem was discovered, assuming it wasn’t obvious, it would take a little while to track it down. You could even end up with the worst case where you’re running in circles because the error you found is the result of another, more serious error. Now, however, we have regression tests for most of the new functionality and for the pages we’ve managed to refactor, but there’s still a long way to go.

    Wading through the source code for the system I come across things that can only be described as code stenches. Yes I’m aware of the term code smell, and that’s where I’m coming from. They really do bother me that much. Pages are often entities all their own with some even doing data access directly. To make matters worse there are many places that business logic and requirements are implicitly implemented without proper comments or mention of it in the XML documentation, which is also sparse. Data access is very heavily tied to the UI in that many of the DataGrids are bound to a DataSet which is the direct result of a database call.

    So where to go from here?

    We have started refactoring our pages to MVP (Passive View) with IoC on existing forms to increase testability/reusability and disconnect the UI from the data and business layers. Don’t yell at me, I know the goal of IoC is not testability but it was a solid means to an end. This will likely continue to be the bulk of refactoring throughout this iteration but we have already added a DomainModel project where all solid domain objects should eventually end up. The appropriate services then need to be refactored to be encapsulated within these domain objects.

    Copyright © 2017 Life, Teams, and Software Engineering

    Theme by Anders NorenUp ↑