As a consultant, one of the more universal things that I’ve observed over the years is managerial hand-waving. This comes in a lot with the idea of agile processes, for instance. A middle manager with development teams reporting into him decides that he wants to realize the 50% productivity gains he read about in someone Gartner article, and so commands his direct reports or consultant partners to sprinkle a little agile magic on his team. It’s up to people in a lower paygrade to worry about the details.
To be fair, managers shouldn’t be worrying about the details of implementations, delegating to and trusting in their teams. The hand-waving more happens in the assumption that things will be easy. It’s probably most common with “let’s be agile,” but it also happens with other things. Static analysis, for example.
If you’ve landed here, it may be that you follow the blog or it may be that you’ve googled something like “how to get started with static analysis.” Either way, you’re in luck, at least as long as you want to hear about how to work static analysis into your project. I’m going to talk today about practical advice for adding this valuable tool to your tool chest. So, if you’ve been meaning to do this for a while, or if some hand-waving manager staged a drive-by, saying, “we should static some analysis in teh codez,” this should help you get started.
Continue reading How to Add Static Analysis to Your Development Process
Here’s a campfire horror story of legacy code that probably sounds at least somewhat familiar.
One day, your manager strolls by casually, sipping a cup of coffee, and drops a grenade in your lap. “Do you think we can add an extra field to the customer information form?” Sure, it may sound innocuous to an outsider, but you know better.
The customer information form is supported by something written almost a decade ago, by a developer long departed. Getting that data out of the database and onto the form prominently features a 60,000 line class called DataRepositoryManagerHelper and it also makes use of a gigantic XML file with odd spacing and no schema. Trying to add a field to that form casts you as Odysseus, navigating between Scylla and Charybdis. In fact, you’re pretty sure that author of the legacy code made it necessary for the assigned developer to cut off and sacrifice a finger to get it working.
Aware of all of this, you look at your manager with a mix of incredulity and horror, telling her that you’ll need at least 6 weeks to do this. Already swirling around your mind is the dilemma between refactoring strategically where you can and running exhaustive manual testing for every character of the source code and XML that you change. It’s now her turn to look incredulous and she says, “I’m just asking for a new field on one form.” You’ve told her before about this, and she’s clearly forgotten. You’re frustrated, but can you really blame her? After all, it does sound a little crazy.
I was asked recently, kind of off the cuff, whether I thought that static analysis made sense for small business. I must admit that the first response that popped into my head was a snarky one: “no, you can only reason about your code once you hit 1,000 employees.” But I understood that the meat of the question wasn’t whether analysis should be performed but whether it was worth an investment, in terms of process and effort, but particularly in terms of tooling cost.
And, since that is a perfectly reasonable question, I bit my tongue against the snark. I gave a short answer – more or less of “yes,” but it got me thinking in longer form. And today’s post is the result of that thinking.
I’d like to take you through some differences between small and large organizations. And in looking at those differences, I will make the perhaps counter-intuitive case that small companies/groups actually stand to benefit more from an investment in static analysis tools and incorporation of the same into their software development processes.
Continue reading Static Analysis for Small Business
After years of pain, I finally found a clean-and-definitive way to get rid of the dreadful issue Could not copy assembly, the process cannot access the file because it is used by another process!
I have no idea how many .NET developers are coping with this issue, but on our side it used to be daily and there are many situations where an assembly file gets locked:
- sometimes VS just load in-process the assembly, or the PDB file or the .xml documentation file, for an unknown reason (usually after a debug session)
- sometimes the culprit seems to be vshost.exe
- sometimes the culprit is the test runner process
- sometimes, after a smoke test session, one just forgets to close all processes that hold assemblies…
- …or sometimes it is just a zombie process that should have stopped but just didn’t!
- and when developing a VS extension, all of those situations are happening more often
When the culprit process was not obviously identified, I started Process Explorer to kill it! And when the culprit process is my current VS instance, it means I need to restart it and interrupt current work for significant time and then lose my mental focus!!
The clean-and-definitive solution to this problem, is this script to copy in a .bat file. This script must be invoked from the VS project pre-build-events. It just moves the assembly file, the .pdb file and the .xml documentation file to a dumb location (if the .pdb or .xml file is missing no problem).
The key is that when a process locks a file, Windows authorizes to move and rename the file. I found the original idea from this stackoverflow answer, that itself found it from a Keyvan Nayyeri blog post that seems to have been removed.
REM This script is invoked before compiling an assembly, and if the target file exist, it moves it to a temporary location
REM The file-move works even if the existing assembly file is currently locked-by/in-use-in any process.
REM This way we can be sure that the compilation won't end up claiming the assembly cannot be erased!
echo $(TargetPath) is %1
echo $(TargetFileName) is %2
echo $(TargetDir) is %3
echo $(TargetName) is %4
if not exist %dir% (mkdir %dir%)
REM delete all assemblies moved not really locked by a process
del "%dir%\*" /q
REM assembly file (.exe / .dll) - .pdb file and eventually .xml file (documentation) are concerned
REM use %random% to let coexists several processes that hold several versions of locked assemblies
if exist "%1" move "%1" "%dir%\%2.locked.%random%"
if exist "%3%4.pdb" move "%3%4.pdb" "%dir%\%4.pdb.locked%random%"
if exist "%3%4.xml.locked" del "%dir%\%4.xml.locked%random%"
REM Code with Macros
REM if exist "$(TargetPath)" move "$(TargetPath)" "C:\temp\LockedAssemblies\$(TargetFileName).locked.%random%"
REM if exist "$(TargetDir)$(TargetName).pdb" move "C:\temp\LockedAssemblies\$(TargetName).pdb" "$(TargetDir)$(TargetName).pdb.locked%random%"
REM if exist "$(TargetDir)$(TargetName).xml.locked" del "C:\temp\LockedAssemblies\$(TargetName).xml.locked%random%"
REM PreBuildEvent code
REM $(SolutionDir)\BuildProcess\PreBuildEvents.bat "$(TargetPath)" "$(TargetFileName)" "$(TargetDir)" "$(TargetName)"
To invoke this script just add this in all your VS project pre-build events command line. If you wish the script name and location to be different, just adapt
$(SolutionDir)\BuildProcess\PreBuildEvents.bat "$(TargetPath)" "$(TargetFileName)" "$(TargetDir)" "$(TargetName)"
Notice that this script does the job no matter the actual configuration (Debug or Release) and no matter if the compilation is started from VS or from any other script.
If you have a sadistic streak and manage a team of software developers, it’s probably high entertainment to dredge up some old, dusty piece of software and then to task them with maintaining it. If, on the other hand, you’re a normal human being and you’re asking this because it’s necessary for your business, you brace yourself. After all, this is legacy software, and the reaction of the team is likely to be quite predictable.
Alright, let’s take a look at this thing. Oh, man, look at that right there. A global variable. And — oh my god — there are dozens of these things. Who even wrote this? And, look at this over here. That’s the kind of idiotic, backward code that we used to have to write 20 years and 6 language versions ago when this code was current. But even when it was current, this code was horrible. This was obviously written by a trained ape.
When you’re a developer, the only thing worse and more contemptible than the uninformed code you wrote years ago, is the code that someone else wrote years ago. Not only is it alien to you in makeup and reasoning, this legacy code also features patterns that have gone out of date or even been forgotten.
But lest you, as a manager, assume that this is simply a matter of developers being prima donnas, consider that an encounter with legacy code bothers developers precisely because it renders them less effective. They’re professionals, wanting to do good work, and the lead balloon you’ve dropped in their lap is an impediment to that.
Continue reading A Manager’s Guide to Legacy Code