Strumenta 
Erik Dietrich is a well known Software Architect with a long experience in consulting. His blog (DaedTech) is a source of thoughtful insights on software development. In particular I was very interested by his usage of static analysis and code metrics in his consulting work.
I am myself a relatively young consultant and I thought it would be very valuable for me to hear his opinion on these topics and in general about consulting in the software industry.
So I wrote to him and he was kind enough to answer some questions.
Introduction
Can you tell us about the typical projects you work on?
It’s hard to summarize typical projects over the course of my entire career. It’s been an interesting mix. Over the last couple of years, though, it’s coalesced into what I think of as pure consulting. I come in to help managers or executives assess their situations and make strategic decisions.
Can you tell us about a project which results exceeded your expectations?
There have been a couple of projects of late that I felt pretty good about. Both of them involved large clients (a Fortune 10 company and a state government) to whom I furnished some strategic recommendations. In both cases, I checked back from time to time and discovered that they had taken my recommendations, executed them, and expanded on them to great success. What I found particularly flattering wasn’t just that they realized success with recommendations (that’s just what you’d expect from a good consultant), but how foundational they found the seeds I had planted there to be. They had taken things that I had written up and made them core parts of what they were doing and their philosophy.
What make your work difficult? What are the conditions which reduce the possibility of a success?
When it comes to purely consultative engagements, the hardest thing is probably gathering and basing recommendations on good data.
If I’m writing code, it’s a question of working with compilers and test suites and looking at fairly objective definitions of success. But when it comes to strategic advice like “should we evolve this codebase or start over” or “how could we make our development organization more efficient,” you get into pretty subjective territory. So the hardest part is finding ways to measure and improve that aren’t just opinion and hand-waving. They’re out there, but you really have to dig for them.
Human factor
When promoting changes to a software development team how important is the human factor? Do you face much resistance from developers?
It’s the most important thing. In a consultative capacity, it’s not as though I can elbow someone out of the way, roll up my sleeves, and deliver the code myself. The recommendations can only come to fruition if the team buys in and executes them.
As for facing resistance, that happens at times. But, honestly, not as much as you might think. Almost invariably, I’m called in when things aren’t great, and people aren’t enjoying themselves. I try to get buy-in by helping people understand how the recommendations that I’m making will improve their own day to day lives. For example, you can reduce friction with a recommendation to say, have a unit test suite, by explaining that it will lead to fewer late night bug hunts and frustrating rework sessions.
How do you win support from people? Developers employed by the company can get defensive when someone from outside comes to suggest changes to their way of work. In your recent post What to do when Your Colleague Creates Spaghetti Code you suggest using data to support your considerations. How well does it work for you? Do you always find data to support your proposals?
Using data, in and of itself, tends to be a way more to settle debates than to get support. Don’t get me wrong — it’s extremely important. But you need to balance that with persuasion and the articulation of the value proposition that I mentioned in the previous answer. Use the data to build an unassailable case for your position, and then use persuasion and value proposition to make the solution as palatable as possible for all involved.
Static analysis
Is there any typical low hanging fruits for organizations which start to adopt static analysis? Anything that can be achieved with limited experience and effort?
I would say the easiest, quickest thing to do is get an analysis tool and set it up to run against the team’s codebase. Those tool vendors know their stuff, and you’ll get some good recommendations out of the box.
Do you work with different language communities (e.g., JVM, .NET, Ruby, Python)? My impression is that on .NET there are better tools for static analysis, and maybe more maturity in that community. Is that your feeling also?
With static analysis, these days I work pretty exclusively in the .NET and Java communities, though I may expand that situationally, if the need arises. As for comparing the static analysis offerings across ecosystems, I’ve actually never considered that. I don’t have enough data for comparison to comment :)
In the Java community there are a few tools for static analysis but I think their default configuration reports way too many irrelevant warnings and this contribute to the poor reputation of static analysis in the Java world. What do you think about that?
I don’t know that this is unique to Java or to any particular tool. Just about every static analysis tool I’ve ever seen hits you with far more than you probably want right out of the gate. I suspect the idea is that it’s better to showcase the full feature offering and let users turn warnings off than to give the impression that they don’t do as much analysis.
A common problem of open source software is the lack of documentation. In your post Reviewing Strangers’ Code on Github you talk about the challenge of confronting with unfamiliar GitHub projects. Do you think static analysis tools could be used to get an overview of the codebase and familiarize faster with the code?
Oh, no doubt about it. I run custom analysis on new codebases just to get a feel for them and gather basic statistics. What’s the length of the average method? How systematically do they run afoul of so-called best practices? How do the dependencies cluster? I could go on and on. I feel like I’d be looking at a codebase blind without the ability to analyze it this way and compare it against my experience with all of the previous ones I’ve examined.
The role of developers
Your next book, Developer Hegemony, is about a new organization of labor and the role developers could occupy in it. Can you tell something about it? And do you think this new organization could be advantageous also for other creative jobs?
In the book, I talk extensively about the problems with and vestigial nature of the corporation in the modern world of knowledge workers. Corporations are organized like giant pyramids, in which the people at the bottom do the delivery work and are managed by layer upon layer of people above them. To make matters worse for software people, a lot of these organizations view their labor as an overhead cost.
I see us moving toward a world where software developers move away from working for big, product companies that make things other than software. I see us moving out from having our salaries depressed under the weight of all of those layers of corporate overhead. A decent, if imperfect, analog, might be to doctors and lawyers. And, yes, I think this absolutely can apply to creative fields as well.
To add on to your post How to Get that First Programming Job what is something that the average programmer is not aware of and could improve their work ?
One of the best pieces of advice I think I can offer is the following, though it’s not exactly technical.
If you’re working and you find yourself thinking/muttering, “there’s GOT to be a better way to do this,” stop! You are almost certainly right, and there is a better way. Go find it. And don’t automate something yourself without checking for its existence.
One of the most common mistakes I see in relatively inexperienced programmers is to take the newfound power of automation and apply it everywhere, indiscriminately. They solve already-solved problems without stopping to think about it (reinventing wheels) or they brute force their way through things (e.g. copy and paste programming). So, long story short, be sensitive to solutions that may already exist or ways to solve problems that may not always involve writing code.
You are clearly an accomplished professional. Could you share one advice for advancing the careers of someone is the software industry?
One thing that drives me a little nuts about our industry is something I described in this post. We line our resumes with alphabet soups of programming languages, frameworks, and protocols that we know, but with little, if any mention of what sorts of business or consumer problems we know how to solve. It’s “I have 8 years of C++” instead of “I can help your team cut down on the kinds of memory leaks that lead to system crashes.”
It will improve your career and focus your work if you start to think less in terms of years and tools and more in terms of what value you can provide and for whom.
Conclusions
I am very thankful to Erik for sharing his opinions. I think there are many interesting takeaways. Two ideas in particular made me think:
- The changing role of developers: maybe some will still prefer the security of corporate jobs but there are undoubtedly many opportunities for those we are willing to go independent.
- We as professionals have to raise the bar. One way to do that is start taking more seriously our job by basing it on data, when that makes sense. Data cannot yet provide all the answers, but it can help and it should not be ignored.
Do you agree?
