Archive for March, 2007
Leah Elle Willeke
Born: 3/28/2007 7:14am
Weight: 8lb 6oz
Head Circ: 13.75″
Mother and baby are both in great shape!
n. Anti-pattern to colocation.
For the last week I’ve been spending a lot of time working alone, in a non-collaborative environment. Sometimes this happens, and it always seems to produce slower, lower quality work. The discipline isn’t quite all there, the testing lags just a bit, the designs aren’t quite as solid or well-integrated… it just doesn’t quite come together when I’m working alone. I’m still doing good work, but not AS good. Other people I know have described the same sentiments. So, why is it that there is still SO MUCH RESISTANCE to colocation?
At my previous job I would push for colocated teams as much as possible, and towards the end of my time there it was finally happening on a consistent basis. Sometimes the logistics were hard because of the short and uncertain nature of some of the projects, but it always helped. It helped a hundred times MORE when everybody on the team embraced the concept and agreed that it would help… magically, it DID help more. Other times, I’ve watched colocation mean that people silently sat in cubes near each other and acted no differently.
C_, R_, and M_… is it any better yet?
<tangent>One of my personal pet peeves is always when somebody is offered a clear way to try something to improve themselves, and refuses to take any advantage of it.</tangent>
Edit: Right after I wrote this, I found http://curtrosengren.typepad.com/occupationaladventure/2007/03/beliefs_that_ho.html in my reader. How appropriate that I find (at least one reason that could be) my answer so quickly.
So, on Feb 15 I was talking to one of my collegaues about this cool thing I found behind his office in Des Moines:
|2/14/2007||Eric||hank||does the big white
building complex behind the holiday inn still say “Becky, will U marry ME?
Chris” on the roof?
|2/14/2007||hanka||Eric||i don’t know – do
you have a link?
And, for fun, I sent it in to Google Blogscoped, who posted my comment here (with attribution):
Today, a month later, I see it come back around at:
With credit given to:
Alas, no credit back to me
So, I had lunch yesterday with an old colleague of mine. I’d link to his blog, but he’s too much of a coward to put his good ideas in front of the masses *nudge* *nudge*.
Anyway, it hit me how much I missed just talking about the theory and practice of software process. It’s been six weeks or so since I left my previous company, and I’ve been responsible for bootstrapping an entire software process into a company for a new development effort. I still remember, but it’s a bit more distant. On the other hand, I AM living and breathing the practical implementation of all the theories we’ve looked at over the last three years, and I’m starting to really appreciate the work that’s gone into the Lean and Agile approaches to software development. It all just fits with common sense AND productivity.
I’ll probably talk more about specific details as time goes forward, but right now we’re “doing”:
- Agile planning (rolling wave + plan to plan)
- Automated builds
- Automated testing (more so every day, Test First is still eluding us)
- Measuring progress by business value produced (not much yet)
- Some degree of Managing Capacity vs. Available Resources.
Keep in mind that we’re doing this in a pretty small setting… we’ve got three full time and three part time developers and one guy doing some good analysis work to feed the development team. Two of the full timer’s are mostly VB6 experts that are currently learning .NET, and they also have responsibilities sustaining the existing version of the product.
So… there’s the raw materials and the approaches… time to go make it work
It seems that working feverishly for a week to prepare a highly mixed development team for live development is a harrowing experience. It’s also become clear that not much is obvious about the process. Everything’s very dynamic and unknown, but today it’s coming together, and I have CHECK-INS… real, live, first day progress-indicating checked in CODE! We have a web service that does a bit, some UI bits that show and bind to (mocked out) data, we’ve got a data model… STUFF IS HAPPENING!
But, this flurry of activity has made it hard for me to post… so… that’s why this is an occasional journey, right?
Oh… and Spraints… I miss you! I wish you were here right now helping me make this happen… I’m not NEARLY as good of a Unit Test enforcer as you are, among other things.
- First, I would craft my resume to meet the job. However, in this case, my resume already fits this job like a glove. In fact, if I were to write my dream job description I think it would be very close to this, but not quite as well-written. Oh, and I only have 7 years of experience, not 8.
- Second, I would make a list of my previous interactions with the hiring manager. Things like attending the Lean Design and Development conference in 2005 and having a couple great conversations about FDD. Then a year later attending SEPG in Nashville and going to hear some great music together.
- Third, I would make sure that the hiring manager knows that I’ve followed his work for a while. Not just the obvious, current blog, but also his older UI Design work, even if he hasn’t posted since 2004. I’ve even read his book, and used it to start changing the culture of a company.
- Fourth, I’d apply other techniques as appropriate. Maybe posting in my blog with a trackback so he knows I was interested. Maybe inviting him to have a couple beers next time he’s in town (always open!). All sorts of ideas.
Unfortunately, it doesn’t matter. I’m quite happy in my new job, and I haven’t been here long enough to consider moving on. Also, the job’s in Seattle, and I’m not. At least for the moment we prefer the eastern half of the country.
But, it never hurts to ask “What if?”
Oh, and David, if you read this – get in touch!
Little round-about here, but I’d like to extend kudos to Terry Gold for the highly professional and courteous way in which he treated one of my friends in a recent exchange. I need to protect the details involved, but I believe in public compliments where possible.
Corporate leaders like him make this world a better place to work and live. For anybody out there looking for a job, consider this a vote, however small, in favor of working for Gold Systems. Terry recently posted about the positions on his blog.
SomeFrame.xaml.cs(20,26): error CS0263: Partial declarations of ‘RibbonPad.SomeFrame’ must not specify different base classes
Good! They used partial classes (as makes sense) instead of the old ASP.NET inheritance approach for defining the relationship between code generated off of XAML and the C# code that goes behind it.
I often find myself using the errors I encounter as teaching aids. I’ve run across too many developers that see that they made an error of some sort, barely glance at the text, and then start hacking away at code to ‘fix’ it without ever actually fixing it.
The most common example used to be the naming collision message when you don’t put either ‘new’ or ‘override’ on a method defined as virtual in a base class. The message is somewhat cryptic, but if you read the whole message you realize it should be ‘override’ in the vast majority of cases. However, the message displays the word ‘new’ early on, so people just tend to use that, the warning goes away, and a bug is introduced.
Note: I’m pretty sure the compiler output changed in .NET 2, so this specific case doesn’t apply as much as it used to. If anybody wants to post the exact error/warning text in a comment, please do… I don’t have a .NET 1.x complier installed anymore.
I believe in reviews. Code reviews, design reviews, architecture reviews, data model reviews, employee reviews, scenario/requirement reviews, UI reviews. Maybe you can tell from that that I’m not a HUGE XP fan.
But, I believe in reviews for a reason. I have 7 years of experience that shows me on both sides of the line that projects with a review culture go well, and projects without a review culture don’t go well. Projects that review most things go well, but the things that slip through have problems. I also know that projects with a review culture generally get to where 99% of reviews have no comments. How is this valuable if it almost never catches anything?
Well, it’s all about the culture. I believe there’s a number of factors that go into it, but I think it really boils down to a few core aspects:
- People do better work if they know it will be looked at
- People feel more collective ownership over the product
- People’s output evolves towards a community standard
That said, the main benefits I get out of consistent reviews are:
- Higher quality output
- More consistent artifacts
- Shorter development time (what!?!? Yes, it’s true)
- More educated and empowered team members
- Evidence (for CMMI, etc)
- Clear local milestones
and the constraints I impose to keep reviews effective are:
- Minimal batch size – keep it short!
- Standardized process – everybody knows how to do it
- Optimized tools – make it easy to set up
- Common reporting – all the results together (and reportable)
- Expert Reviewer – primary reviewer is always the most qualified available individual
- Required resolution – all raised issues are explicitly addressed
These things combine to make reviews very easy and effective… qualitatively justifying the needs I need.
Well, fast forward to my new job, and my pronouncement that “everything will be reviewed”. The two guys from Iowa went “ok”, and the two local developers went “ummm…. I guess…. but that will be the first thing to go if things get tight”. Now, that just hit me wrong. At the time, I explained that I was pretty firm about this, and that I felt it was more important to review during the crunch times. I then went on to explain more about the process I used for reviews and went through some of the information I typed above.
But… the verdict’s still out. I’m a salesperson now!
Probably a bit negative of a title, but there’s some real value in this approach. Two weeks ago I spent 20-30 minutes describing the benefits and strengths of Team Foundation to a table full of my colleagues. Only one or two of them got it, the rest had no inclination to pursue the matter in any way.
Today I spent 5 minutes with one of those people that didn’t get it, and I was able to train them on TFS well enough to perform their job functions and left with them saying “This is a really good system for bringing all this stuff together”.
What’s the difference here? In the second case, I was demonstrating activities that directly benefit the individual in a highly visible manner. This is the key. Abstract, high-level overviews are nice for people actively looking for something to solve a problem, but people being asked/forced to use a new system don’t care for that. They won’t accept it unless they see benefits for themselves. Hence, greed-based training.
What is it really?
From my personal experience, greed-based training is really just applying andragogy‘s concepts in a one-on-one synchronous environment. Hard to write a process for, but easy to do if you know the person involved. For example, when I was selling TFS at my previous company over a period of months, each of the managers had a different image of what it was, because I communicated to each manager the aspects of TFS that helped with the challenges particular to that manage. Later, I was able to pull it together as people initially thought they were talking about different things, but realized that one system really could do it all.
So – if you want somebody to buy into something, talk about their benefit, not somebody else’s.