Mike Wood and I are organizing an open spaces event on 9 July at Max Training's Mason facility. The event's still being fleshed out, but we're looking at running from 6pm to 9pm. Max has a crapload of space in their Mason facility, so we ought to be able to run five or six concurrent discussion groups.
Stay tuned for more details!
I spent an hour or so working with a couple folks from Red Gate this morning to run through the latest build of their ANTS Profiler v4.0.
ANTS 4 is still in EAP (download latest bits here), but I was awfully impressed with the state it's in. I downloaded the bits, installed it, ran a quick session on a monster WinForms app I've worked on in the past, and quickly got down to the guts of some possible performance issues. The UI's nicely done, and I was very, very impressed with the app's responsiveness. I'd all but given up on ANTS 3 and dotTrace because of nearly unusable performance while trying to profile a couple apps.
ANTS 4 still has a way to go. There are some bugs running around, and some UI tweaks need to take place, but overall I liked what I saw with this version. You ought to go have a look at it if you're interested in an easy to use profiler.
<disclaimer>I get some software from Red Gate for free because of my MVP status. That doesn't stop me from criticizing if needed.</disclaimer>
The great gang at the Cincinnati .NET User Group invited me to participate in a panel discussion at their meeting tonight. I was honored to be up front of the group with Tim Apke and Ed Sumerfield, both two sharp guys with much more technical experience than me. All three of us have, as Mike Wood put it "a long history in IT" which I think was Mike's nice way of saying all of us are old farts.
The discussion was very free form and hit a lot of great topics ranging from specialization or generalization to estimation accuracy to workplace culture. Dealing with new technology was big one, as was questions about breadth of experience (outside of the strictly technical domain). The value of certifications was bandied about with a mild consensus seeming to form around them being good in the proper context: use 'em if you need to prove your chops early in your career, but don't overly fixate on them.
Hearing Tim's and Ed's perspectives along with those of the audience was a great experience. Tim and Ed are wicked smart and have some great insight into how to steer one's career along. Tim was emphatic about taking ownership of your own career. In a sidebar after the meeting he compared taking care of your career to taking care of your car. You keep your car's tires in good shape, change the oil, and give the vehicle a tune up on occasion. Same concept applies to your career. Ed also impressed the hell out of me with a number of things, not the least of which were his closing comments which was a short haiku along the lines of "own your path" but he said it way more better.
One of the regulars there (forgot your last name, Jamie -- sorry!) hit me with the last question of the evening and asked how I manage to balance work, community involvement, book writing, and time with the family. That one hit very, very close to home and got me choked up in a major way -- not what I would have preferred for my last question of the evening, but there you have it. I don't always do a great job of work/life balance, but I've made some tough choices in my career to favor family over work. I've passed up great opportunities, I've struggled with sub-optimal part-time positions, and I've left a high paying job to be unemployed at home in order to take care of the kids. My career would be in a much, much different spot had I chosen career over family.
The cons of those decisions are that I'm not some internationally recognized expert traveling around the world talking at TechEd Barcelona or running some wicked cool project in Dubai, nor am I billing out at $500 per hour while working at iDesign or some similar firm. The pros of those decisions are that I got stay at home with my daughter and son while they grew up, and I'm not traveling three or four weeks of each month while my wife and kids live their lives without seeing me. (Another con: costs of therapy for two kids when they hit teen years and figure out how screwed up they are after having had me as their primary caregiver...)
So to those of you who thought I got emotional about that question, you're right. It's really at the core of who I am, even if I don't get it right as often as I should. (That's me, too, BTW.)
Actually, forget all that. It was really allergies. Sorry.
In any case, the panel discussion at the group was an excellent evening. I hope attendees got something useful out of it!
All projects acquire technical debt in one fashion or another, and in varying quantities. I've been looking at a couple past projects to identify areas in need of some debt repayment should the projects move into their next phases.
Apropos, then, that I ran across a great post from Steve McConnell on technical debt. I particularly like his sections on communicating about technical debt and debt safety. Be sure to follow Steve's links to Ward Cunningham's and Martin Fowler's articles.
Good reading!
The ThoughtWorks Anthology, published by Pragmatic Press, ISBN 193435614X
This is a terrific book loaded up with 13 short, concise, golden essays from ThoughtWorks leaders like Martin Fowler, Neal Ford, etc. Each topic covers something pretty vital for those of us who care about being somewhere near the top of our chosen craft. Topics include solving the "last mile" problem between development and release, Ruby DSLs, polyglot programming, single-click deployment, and a bunch of other great reads. Each article is extremely well-written and useful, but I found a subset of the book particularly compelling.
Unfortunately, I only heard parts of Neal Ford's "Polyglot Programming" at his keynote at CodeMash 2008. I was thrilled to get to read his article in this book on how to leverage different languages on the same platform to solve different problems.
Jeff Bay's piece "Object Calisthenics" strongly reminded me of the glorious work The Practice of Programming from Kernigan and Pike in its emphasis on clean, simple, clear code. I'm all fired up to refresh my coding practices with Bay's exercise using nine points for pushing yourself into writing better object oriented code.
"Refactoring Ant Build Files" from Julian Simpson, along with Hatcher's Java Development with Ant, should be mandatory reading for anyone dealing with build files -- regardless of what build environment you're using.
Other big winners for me were the testing articles by Kristan Vingrys and James Bull, Dave Farley's work on one-click release, and Stelios Pantazopoulos's article on project vital signs. Of course, the remaining articles are also winners, it's just that these six or so really struck home with me.
Overall it's a fantastic work and I'm really glad I've got it on my bookshelf!
Ran across references to the new Alt.NET Podcast and checked its inaugural episode on the drive to work this morning. The first episode was great, and I'm looking forward to hearing more from the 'cast!
Subscriptions available through iTunes or POR (Plain Ol' RSS).
I've been struggling for some time to ensure that our agile projects get a true representation of value delivered to the client when schedules and budgets are being discussed. I think our flexibility to deliver on client-driven scope change too often fails to show how we're really doing, particularly in e-mails or on the Great Game of Business boards we use at Quick.
For example, a project I just wrapped up the first phase on used SharePoint Excel services to host a complex workbook the client uses to show total cost of ownership for heavy equipment. The original scope was for one set of features at a specific estimated cost. We ran over estimates on a couple tasks (Excel Services is a difficult technology, especially when you're trying to work around its limitations) and beat a couple others. The big delta, however, was that the client had us drop a couple items and add in a significant amount of new features. Overall the client was extremely happy with what we produced.
Unfortunately, every mail regarding schedule and budget always went out the door saying we were slightly behind schedule and slightly over budget. I'd have to immediately follow up and say "Yes, but look at the added scope and value we're bringing to the client at their direction." Furthermore, the GGOB board shows a variance on our project, nicely written in red because we were over the initial figures on a time and materials project.
This mindset comes straight out of the PMP world and I'm struggling with how to get this changed in our environment. Metrics are good, as are BVC information radiators, but only if they're a fair and and accurate reflection of where a project's at. That accurate reflection should include some measure of succeeding on client-driven scope change -- after all, shouldn't we be all over recognizing the value we've brought to the client?
I'm not sure where this will end up going, but I'm noodling over some ideas. I'd love to hear suggestions if you've got 'em.
I've never claimed to know all the answers. Actually, I'd be happy if I could answer more questions than not... That said, if I can't answer a question, I generally know right who to reach out to for answers.
This comes in to play time and time again in our line of work, particularly since we're expected to be able to solve so many different problems in so many different technologies/platforms/whatever. I ran in to this recently with a performance issue and was able to solve part of the issue by reaching out to Bruce Lindman, the senior DBA we have on staff.
I'd isolated some connection timeout issues to a query that was taking almost four minutes to return. The query was built to handle sorting out some permissions across a large set of data and was working with a lot of records from a master table and association table. The developer who had originally written the SQL had broken out the sproc into several different functions in order to modularize it for testing and for clarity. Everything looked pretty good, and all of our moderately complex use cases passed just fine in the test environment. Unfortunately when we rolled in to the test environment at the client site we found the really bad timing issue. Ick.
Bruce immediately identified the problem: the user defined functions were returning tables of result sets -- and those tables aren't indexed. Large amounts of data for intermediate results. No indexes. Small problem there. Bruce spent 30 minutes or so rewriting the query to bring the functions back in to the main sproc, tweaked a few things, and ended up cutting the query from nearly four minutes down to 22 seconds.
That's a great improvement in a technology area that I'm, well, frankly, sucky at best. Being able to call in a specialist let me focus on a couple other issues which were also contributing to the performance problem. Those other areas (overly heavy biz objects, pooling issues) were in my area. SQL complexities aren't.
Our industry's grown too broad for us to be experts at everything, even if clients expect us to be. I think all we can ask for is that we form groups or teams of specializing generalists: folks who are very solid at a wide range of skills, but experts in one area. That lets us have a cadre of resources to reach out to when we're in over our heads, which happens more often than we'd like to admit...
UPDATE: One blog reader, blocked from commenting by an evil corporate proxy, pointed out a great article by Scott Ambler on this same topic.
Subject To Change, Peter Merholz, et. al, published by Adaptive Path. ISBN 0596516835.
This book at first glance seems awfully similar to Scott Berkun's The Myths of Innovation, but there's enough distinction to make it worth a separate read.
Subject to Change is short, concise, and very well-written. It offers up insights on how companies can be more flexible to meet market changes by working in new ways for solid customer research, product design, and agile approaches, among other things.
The book's nicely done and is filled with good examples of how some companies have come up with concepts which completely changed the industry. Kodak's first box camera is an example of a product which fundamentally changed how companies treated their customers. ("You press the button and we do the rest.") Kodak also gets slammed for their ignorant approach to the digital camera age -- failing to adapt to a changing environment isn't a great way to run a business...
This same theme runs through the book: approaches that have worked wonders for companies contrasted with flops that haven't. Successful approaches almost always come from businesses which have spent time understanding their customer base; flops come from companies which do silly things like create hardware which is feature-scarce, expense, and hard to use without having ever talked to a customer.
I liked most all the chapters and found the ones on design competency and agile particularly interesting. No surprise about me liking the agile chapter since I'm a nut about agile software development! There are also a number of great discussions on brainstorming UIs, layouts, and product prototypes, something which I think gets little or no coverage in other works.
Overall it's a good read. It didn't grab me as much as Berkun's Innovation book, but it's a solid addition to my bookshelf all the same.
Subscribe (RSS)
The Leadership Journey
