Digging with spoons – the case against progress

Say you need to dig a big hole. Do you dig with a spoon or a shovel? Most progress-oriented developers would think “of course we use shovels”, but they continually get surprised when on their real projects the team still essentially digs with spoons. Why? How could someone possibly want to dig with a little spoon instead of a big shovel? Sure, I favor shovels, but I’ve seen over the years that people think very differently, and some people could offer lots of reasons to use spoons instead:

1.       We already have a spoon right now.

2.       It won't really take that long to dig with spoons.

3.       I used a spoon before; you should use a spoon to.

4.       Using a spoon teaches you how to dig, when I was in school they taught us to dig with spoons.

5.       Using a shovel is the lazy way out.

6.       A spoon gives you the granularity you need, you don't really know what you're digging if you have a shovel.

7.       The boss thinks spoons are better (that's how he did it back when he dug).

8.       If we switch to shovels now, that would be admitting we were wrong before.

9.       We need objective measurements (committees, score cards, analysis docs) to truly show if a shovel is better than a spoon.

10.   You’re just advocating using shovels because you read some blog about it.

11.   That big shovel is too heavy; spoons are lighter so we can dig faster.

12.   The shovel wasn’t built here.

13.   You’re not part of the process improvement team, so don’t worry about it.

14.   We’re already successful, so we don’t need to change how we do things.

15.   Well, I actually read that shovels are bad.

16.   Spoons were working fine before you got here.

17.   My last company used shovels, and they went out of business.

18.   Your attempt to change our process means that you’re not being a team player.

19.   Your job is to dig, focus on that.

20.   We can use spoons for now, and then use shovels later.

21.   Not everyone knows how to use shovels, and we can't afford the training costs right now.

22.   We’re under contract to use spoons.

23.   The boss’s boss is friends with a spoon manufacturer; we really ought to keep using spoons.

24.   Are you so special; is a spoon not good enough for you?

25.   If we use spoons, there won't be enough work to do and people will lose jobs.

26.   Our competitors use spoons (I heard), so we should be fine.

27.   Our competitors use shovels, so doing something different gives us a competitive advantage.

28.   This discussion of spoons vs. shovels is just a distraction from the real goal of digging.

Each of these brings to mind some analogy with some past software project where the “slow” way (i.e. spoons) was preferred. Part of empowering a team is to overcome this sort of thinking to show that it’s really in the team’s best interest to use shovels.

How is a senior developer different from a junior developer?

There is not one right answer. It’s easy to say “a senior dev knows more and does more”, but I think there’s an additional dimension – a junior dev is merely expected to code to the spec, whereas a senior dev fundamentally takes responsibility and ownership for improving everything they encounter.

Here’s a braindump; obviously my opinion. Not a complete list, and not a one-size fits all. I was light on the exact technical requirements (as that changes), and focused more on the concepts. Perhaps in another blog post I’ll do a braindump of what a senior dev is not  (i.e. how is a senior dev different than a tech lead or architect). I’m using C# and .Net as an example, but you could easily substitute those.

There’s also an interesting matrix here.

Writes good code that just works

·         Be able to code to specification is assumed. Should be able to leverage experience and past domain knowledge to fill in some gaps in a spec. Does not need everything explained in complete detail.

·         Writes working code that handles non-happy path and has low bug count. Can quickly create code – does not need to continually refer to reference documentation.

·         Codes for non-functional requirements, like performance, maintenance, testability, security, etc…

·         Can write code with the minimal length and complexity.

·         Thoroughly unit tests applicable code.

Respected by peers

·         Has written a module or tool directly used by others on the team. A senior dev does not just write code in their corner.

·         Can review other’s code and suggest improvements that others will actually implement.

·         Other developers ask for your technical opinion

Experience

·         Has built end-to-end products, through all tiers, that ran in production for multiple  releases

·         Has written 10,000+ lines of C# code that passed code review

·         Has created at least 4 different Visual Studio project types (WinForm, web, WinService, Console, etc…)

·         Has created developer tools and utilities besides just visual studio. I.e. has used a profiler or visual studio plug-in or code analyzer or code generator.

·         Has troubleshot a production security or performance error.

·         Has written multi-threaded backend code

·         Has at least 1 technical niche of expertise

Takes Responsibility

·         Does actions to make other developers better, such as writes reusable code, mentors, solves critical path problems, automates a previously manual task, etc...

·         No longer just focused on development, but helps improve the process of development.

·         Can refactor legacy code without a formal project

·         Can resolve unanticipated coding or validation problems without pulling in a more senior resource

·         Can pick up new technologies without formal training (may need formal training for an entirely new platform)

·         Continually looks for code reuse and ways to decrease technical debt.

·         Can tell management what the developer needs in order to be more productive

Has platform-specific knowledge

·         This is the standard list you’d see on a job description (“Knows threading, diagnostics, reflection, IO, etc…, Can explain 5 design patterns, etc…)

Free WMI Code Creator - WMICodeCreator.exe

I’ve tinkered with WMI in the past, usually to find some IIS, network, or process information on remote machines where there wasn’t a readily-available API. I realize as the world of .Net APIs expand, the need for WMI shrinks, but it’s still an underlying technology that lets you do “magic” when there appears to be no other way.

However, the problem I’ve often had with WMI is finding the exact query to run. To my knowledge, it didn’t have intellisence, and I never clicked with the reference manual. I recently found a tool that makes it easy to generate WMI snippets – the free WMI Code Creator v1.0. Yes, this tool is from 2005, yes that means I am absolutely no WMI guru, but I still wanted to pass it along.

The tool provides a GUI to select the various namespaces and classes from which to construct your WMI query, and then lets you select the properties (“columns”) to return.  Then, it lets you execute the code on the fly. The tool just worked. Here’s a snippet of what it returns for querying process information.

using System;

using System.Management;

try

{

       ManagementObjectSearcher searcher =

               new ManagementObjectSearcher("root\\CIMV2",

               "SELECT * FROM Win32_Processor");

       foreach (ManagementObject queryObj in searcher.Get())

       {

              Console.WriteLine("-----------------------------------");

              Console.WriteLine("Win32_Processor instance");

              Console.WriteLine("-----------------------------------");

              Console.WriteLine("Family: {0}", queryObj["Family"]);

              Console.WriteLine("ProcessorId: {0}", queryObj["ProcessorId"]);

              Console.WriteLine("ProcessorType: {0}", queryObj["ProcessorType"]);

       }

}

catch (ManagementException e)

{

       MessageBox.Show("An error occurred while querying for WMI data: " + e.Message);

}

Chicago Code Camp 2012

This Saturday, we had another successful Chicago Code Camp at the CLC campus. About 400 signed up, and we estimate about 180-200 showed up based on sign-in logs. It was a "free" event thanks to our dozen sponsors and 30+ speakers. The courtyard was filled with impromptu developer discussions. Our morning registration and lunch lines flew  with almost no wait time. All around it was a wonderful event. I'm always honored to be a part of such an event.

Presenting at SDC on Build Servers and Metrics

UPDATE: Download PowerPoint Here

----
I'll be presenting at the Software Development Community (SDC) on Sunday, April 1st on Build Servers and Metrics. The SDC meets in Oakbrook.

http://www.meetup.com/SoftDev/events/43412322/

ALM tooling: Empowering teams with build servers and metrics
Everyone knows that automated builds are a good thing, but many teams don't leverage them fully because it's hard to get started. Tim will go over practical techniques and concepts for automating builds with TFS and MSbuild. Once you have an automated build, there are dozens of steps you can hook into it, such as metrics. Tim will walk through several core metrics, including line count, code churn, duplication, complexity, and test code coverage, as well as the concepts and pitfalls for adopting these within a team.

Chicago Code Camp is coming May 19

The fourth Chicago Code Camp is coming to CLC on May 19:

http://www.chicagocodecamp.com/

You can register here:

http://chicagocodecamp2012.eventbrite.com

Chicago Code Camp is a free, one day conference on Saturday May 19th, for developers of all skill levels and interests with multiple sessions running side-by-side throughout the day.

Bluffing Line Count and why it's still useful

I'll take it as a given that every developer knows that line count is a problematic metric. You know you got problems when someone with power thinks that "Homer did twice as much work because he wrote twice as many lines". Why is line count so unreliable? Here are some reasons to get started:

1.       Significant lines vs. raw, i.e. whitespace, comments, brackets on new-line

2.       New code (creates lots of it) vs. production bug update (5 hours to fix 1 line)

3.       Generated files (proxies, designer) or massive code generation

4.       Copying 1000 lines from open-source online (algorithm works, so low risk, but you've added a lot of code)

5.       Complexity of code, i.e. a 20-line algorithm may be more work than 1000 line of casual UI and data hookup.

However, if you're trying to coordinate more than 10 developers, and you have no other metric, line count still has some value because it quickly tells you something is going on. (i.e. the "something is better than nothing" philosophy.) You've got to look at the trends, not the absolute values.

·         It's useful to know if your team's average developer produces 500 lines of code (LOC) per week (of course this varies from team to team), then seeing someone produce either 50 or 5000 should catch your attention. Sure, there may be a good reason, but you at least want to be aware of what that reason is. Is the guy generating 5000 massively copying and pasting code, re-inventing the wheel for quick-to-write utility code, or using a passive code-generator instead of your team's ORM framework? Is the guy only doing 50 not checking anything in, and waiting to surprise the team with 4 weeks of work the day before code freeze for one "glorious" check-in?

·         Line count is ubiquitous and everyone can understand it.

·         Line count is very cheap to calculate; many tools can provide this.

·         Line count is the basis for two more relevant metrics: code churn, which tells you how many lines per file is changing per changeset (and hence per developer), and code duplication (I personally love Simian for this).

·         You can also write reports splitting line count by file name to see the ratio of business, entity, data-access, unit test, UI, etc… For example, is someone checking in 1000 lines of business logic, but with zero unit tests? It's something worth investigating.

You cannot reduce an art like code craftsmanship to auto-generated metrics. But the metrics do offer clues to what is going on.  It's good to be aware, but never judge a developer on metrics alone.