Friday, November 30, 2012

I was hosting a BBQ over the summer, giving me a chance to use my very rusty "grill master" skills. Stepping away from the grill for just a few moments, I looked back to see huge flames spilling out of the grill. Luckily for me, one of the guys nearby just stepped in and quickly turned down the heat. He didn't track me down and notify me of the flames, ask me if it was okay, or delay in any way – he just did it. By the time I got back to the grill and all was calm, he casually mentioned turning down the heat. He had done many BBQs before, and he just "got it".

That's what a good team wants from its developers – people who just get it. They see a fire, and deal with it. Sure they keep management informed, but they don't make management a bottleneck with and endless stream of questions. These are developers who write that extra null-check, create the defensive code that defaults to a safe value if a param is missing, make a safe business assumption for a validation rule, upload a tool or patch to a shared drive so the next guy can easily get it, you get the idea… In each case, they could do it the "wrong" way, but they risk that and do it anyway.

I think this ultimately stems from management. First, management needs an atmosphere that encourages common-sense risk. Micro-management creates an aura where developers are scared to do the slightest action without multiple levels of approval for fear that no matter how obvious it may seem, it was the wrong thing. If you see the hamburgers burning, but you're not "allowed" to touch the grill, you'll just sit and watch dinner burn, and no one wins. Second, management needs to delegate and encourage and build up developers to take such "risks". Start small. It's much like a parent training their kids. Sure eventually someone guesses wrong (say they pick the wrong default validation rule and hence need to re-code it), but if they got the previous nine right, then your team comes out ahead. It sure beats eating charcoaled burgers because the team has been trained to only allow managers to turn down the grill.

Monday, August 20, 2012

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.

Thursday, May 31, 2012

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.

Wednesday, May 30, 2012

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.

Wednesday, May 23, 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.

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.

Sunday, February 26, 2012

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:

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.

Wednesday, January 18, 2012

I wasn't the most popular kid growing up. Even in college as I lived up to the analytical stereotype and stayed home studying (a better word would be "experimenting" or "training"), my party-going acquaintances would assure me that I was investing in the wrong thing. "It's not what you know, it's who you know. So don't spend so much effort with the books when it's the relationships that matter." And there certainly is some truth to this. We've all seen the stranger's perfect resume get passed over for the friend's average resume (the stranger is by definition unknown, and therefore risky, so there is business rational to pick the safe candidate over the risky one). People ultimately make the decisions, so people are important. It's one reason I so actively endorse the community user groups.

However, there must be balance. There are three caveats that this cliché misses:

1.If what you know is valuable, then people will want to know you. Even a hermit who cures cancer will begrudgingly become famous. Recruiters in every major city are scouring over LinkedIn, user groups, monster, dice, and every online job board trying to find good candidates, offering bounties, and poaching top talent from competitor's. In other words, "what you know" will quickly open doors to "who you know" (and "who knows you").

2.Really, it's not "who you know," but "who knows you." Sharing an elevator, or even a lunch, doesn't mean that they'll risk their reputation giving you a referral, or that you can "phone them for a favor".

3.There are talkers and doers. Talkers can drop a name for every occasion, have 500+ social-networking friends, and can truthfully say things like "Oh, I know Acme's Chicago director, Bill, we met at last Autumn's pumpkin-throwing contest…" They could get the interview with their connections, but they could never pass the interview itself.

Of course, with "what you know" vs. "who you know", like most two-way debates in life, you'd prefer both. But in the field of software engineering, you can never sell-short the "what you know".

Monday, January 16, 2012

Visual Studio had code complexity metrics, but they were only available in the GUI. (At least for code coverage you could call the private assemblies and roll your own command-line tool.) However, VS 2010 offersa free power-tool that lets you run complexity metrics from the command line! The result is an xml file, so you can leverage that for anything you need.

Part of the cool thing is even if you're still on VS2008 (!), and you can't buy a 3rd party tool (NDepend!), you can still use the 2010 power tools to call .Net 3.5 assemblies. So, you could install VS2010 on your build server and use the power tools on 2008 builds.

Thursday, January 5, 2012

I was trying to run some metric calculations on files within a changeset, but I only wanted new files – i.e. I wanted to filter out merged, branched, or renamed files. For example, if someone created a branch, that shouldn’t count as adding 1000 new files.

One solution I found was to check the Command column of the TfsVersionControl.dbo.tbl_Version table. I realize the TfsVersionControl is a transactional database, and reports are encouraged to go off of TfsWareHouse, but that didn’t seem to contain this field.

Here’s the relevant SQL (NOTE: this is for VS2008, I haven’t tested it on VS2010).

select

CS.ChangeSetId, FullPath, Command, CreationDate,

case

whenCommand in(2,5,6,7,10,34)thencast(1 asbit)

elsecast(0 asbit)

endas IsNew

from TfsVersionControl..tbl_Version V with (nolock)

innerjoin TfsVersionControl..tbl_ChangeSet CS with (nolock)

on V.VersionFrom = CS.ChangeSetId

where CS.ChangeSetId = 20123

The question becomes, what does the “tbl_Version .Command” column mean, and why those specific values? I couldn’t find official documentation (probably because it’s discouraged to run queries on it), so I did a distinct search on 50,000 different changesets to find all values being used, and I worked backwards comparing it against the Team Explorer UI to conclude it appears to be a bitflag for actions:

Command

Bit value

add

1

edit

2

branch

4

rename

8

delete

16

undelete

32

branch

64

merge

128

Recall there can be multiple actions (hence the bit field), such as merge and edit. So, if you want to find new code – i.e. adds or edits, then we’d take the following bit flags: 2, 5, 6, 7, 10, and 34.

Is New?

Bit value

Actions

Yes

2

edit

Yes

5

add (folder)

Yes

6

type/edit

Yes

7

add (add file)

No

8

rename

Yes

10

rename/edit

No

16

delete

No

24

delete,rename

No

32

undelete

Yes

34

undelete, edit

No

68

branch

No

70

branch, edit

No

84

branch,delete

No

128

merge

No

130

merge, edit

No

136

merge,rename

No

138

merge,rename,edit

No

144

merge,delete

No

152

merge, delete, rename

No

160

merge, undelete

No

162

merge, undelete, edit

No

196

merge, branch

No

198

merge, branch, edit

No

212

merge, branch, delete

Of course, this is induction, and it’s possible I may have missed something, but given a large sampling and lots of spot-checking, it appears to be reliable.