Book: Working Effectively with Legacy Code

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_working_effectively_with_legacy_code.htm]

A while back I was working on some huge legacy security component. I found it quite challenging, especially the legacy code part of it. Afterwards I thought about writing a blog post on "tips for working with legacy code". While I never got around to that, I did recently finish reading Michael Feather's excellent book Working Effectively with Legacy Code. His book is infinitely better than any measly blog post I could have come up with.

 

This book is awesome. I encounter people who effectively (and naively) say "just write it perfectly the first time." However, that misses the point. For example, many devs weren't even around when the system was first written - they're inheriting someone else's code. The author tackles the problems head-on with concise examples and clear guidance. The book has three parts: the first part starts as a general overview and then explains why this is really a problem, the second part offers tons of practical ways to test difficult code, and the third part explains how to break dependencies so that the code is no longer so tightly-coupled.

 

Two main themes of the book are (A) you want to be able to somehow write unit tests for this code, and (B) tightly-coupled code makes that very difficult. For example, if you've got a some "Employee" object, and its constructor requires a live database connection, singleton references, external configs, and web HttpContext access (like session state), you're somewhat screwed. He then proceeds to show how to salvage that situation by making low-risk changes that allow you to pull the code into test harnesses.

 

You've got to love empathetic chapters like "it takes forever to make a change" and "I can't get this class into a test harness". I think this is a perfect book for anyone dealing with legacy code.

What if you're a big fish in a small pond - life without a mentor?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_if_youre_a_big_fish_in_a_small_pond__life_without_a_m.htm]

In the ideal world, you'd work at a perfect company that surrounded you with wise mentors who could guide you past those insurmountable learning obstacles. Of course you'd work hard and take a stab at it first, but you'd know that an experienced guru would always be there to catch your back. But obviously, life isn't ideal, and many developers simply don't have that safety net of available mentors. Especially eager developers who work at small to mid-range companies might need to deal with being a big fish in a small pond. It's great that you can help your coworkers - but who is helping you? For example, I talk to a lot of guys in 5-person shops, and they're always the goto guy, always the one setting the path.

 

I hear it can get tiring. Here are some ideas to deal with it:

• Find others who are "bigger" - books, blogs, online forums, user groups. What's amazing about the internet (as opposed to 20 years ago), is that you can get access to all these brilliant minds out there.

• Leverage your coworkers niches. - Chances are, even with a 5 person team, the total-sum-knowledge of the entire team is greater than yours, i.e. someone there knows things that you don't. Maybe you're a star UI developer, but the DBA can teach you a few tricks. While this may not take you deeper in your own niche, it will help you spread out and be more well-rounded.

• Potentially leave your job - Sometimes you've out-grown your current job, and it may be time to "move on". For example, a lot of people go to industry leaders like Microsoft because they want that learning opportunities that a star company provides.

While it may provide a learning disadvantage to always be the one breaking-the ice, or drilling through rock to pave the path, there is an advantage. It forces you to pro-actively learn and demonstrate leadership skills, and a lot of companies (and life situations) value that sort of thing.

LCNUG: NHibernate

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/lcnug_nhibernate.htm]

Yesterday, Robert Dusek and Hudson Akridge of GFX presented on NHibernate, which is a powerful way to persist data. The meeting was a big success - we had our largest turnout - about 20 people. There was a lot of good dialogue both before and after the presentation. We also announced the progress on the new LCNUG website, including our flourishing job board (6 jobs from 3 different companies so far).

How to increase chances of being allowed to research

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_to_increase_chances_of_being_allowed_to_research.htm]

For any software project, there's always something new to research. Even if the flood of new technology suddenly freezes, most projects would still struggle just to catch up to the existing technology. While a lot of small to mid-size departments don't have dedicated research teams (or even tasks), here are some ideas to subtly incorporate research items into your schedule.

• Focus on small, concrete tasks that management cares about. A web app probably cares more about research JQuery or Silverlight than it cares about the WinForms DataGrid, or something ambiguous like "incorporating web best practices" (what does that practically mean?)

• Emphasize the low-hanging fruit with the highest return - Not all research tasks are equal. A SQL static code analyzer (which benefits everyone on the team) may be far more profitable than some crusade to make sure no-one uses Hungarian notation n C#.

• Piggyback off of existing assignments. If you're implementing an Aspx page, it may be the time to investigate Ajax, JQuery, or even something smaller like just JSON - you'd essentially have "the wind at your back". You could research an unrelated task, like hosting your  build process on virtual machines, but you'd be doing it all alone, without the support of your current assignments.

• Focus on just one or two things at a time. You could easily list 50 things to do - new technologies, tools, refactoring, open-source projects, controls to integrate, upgrading your framework, testing, automation, code generation, etc... If you juggle too much, it will all crash and you'll have nothing.

• Finish what you start; Actually deliver something - "A bird in the hand is worth two in the bush." For many departments, the thinking is it's better to have a weak solution that's completed (and hence usable - i.e you have something), than a powerful solution that's "still in progress" (and hence unusable - i.e. you have nothing.). The workplace is ablaze with buzzwords. Anyone can spew forth buzzwords or suggest grandiose visions, but at the end of the day - management cares about things that are actually done.

• Work incrementally - Management may initially not allot 4 weeks to research how Ajax benefits your web app, but you could spend a day here integrating it, a day there using an update panel, another day later pulling in the Ajax Control Toolkit. Yes, it's slower, but it's better than nothing.

• Establish a track record to "earn" bigger opportunities - As you gradually get research items actually completed, you'll become more credible, and will therefore probably be given more opportunity to research bigger tasks. For example, an unknown new-hire may be allowed to "explore" for a day, but a credible senior developer - who's already delivered many successful features - may be allowed to explore a research task for weeks.

Real Life: Taking the fridge door off

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_taking_the_fridge_door_off.htm]

 To fix a normal squeaky door is relatively easy - just tap out the axle that joins the hinges, oil that, tap it back in, and... no more squeaky hinge. After the 20th such hinge, I got the hang of it. So, whenever my wife says the hallway doors are squeaking (translation: "please fix them"), I'm looking forward to an easy task. However, the other day she mentioned that the fridge door was squeaking. Now that was an issue. Taking off one hinge at a time for a hallway door is easy - but fridge doors aren't built like hallway doors, so you need to take the entire door off. Taking off the entire fridge door is hard (at least for me). But, alas, there was no other way. So, I got out the necessary tools, and took the entire fridge door off, oiled the door axle, and... it too stopped squeaking! The moral is that, just like in software development, people often need to take one step back before taking two steps forward. Maybe that means throwing away precious code, reading a long article instead of just jumping to a quick solution, writing a unit test harness, or something. The current problem might require you to "take the fridge door off".

Ajax Issue: "The history state must be small enough to not make the url larger than 1024"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/ajax_issue_the_history_state_must_be_small_enough_to_not_m.htm]

I got a really weird Ajax bug the other day. I was working on an ASP.Net website and got this cryptic error whenever clicking a postbacking button within an Ajax update panel.

Microsoft JScript runtime error: Sys.InvalidOperationException: The history state must be small enough to not make the url larger than 1024

Then, re-clicking a tab, you get another ajax error:

Microsoft JScript runtime error: Object doesn't support this property or method
At this line:

if (element.tagName && (element.tagName.toUpperCase() === "SCRIPT"))

In this specific case, the element tag didn't have the toUpperCase() method. It had worked before, everything seemed strange. To make a long story short, it appeared to be a problem from installing VS SP1.  We had installed the old Ajax toolkit. The new SP updated the System.Web.Extensions.dll assembly in the GAC, which created different script resource files.
 

Old (which worked)	New (which did not work)
Assembly Ver: 3.5.0.0 File Version: 3.5.21022.8 C:\MyProject\System.Web.Extensions.dll	Assembly ver: 3.5.0.0 File Version: 3.5.30729.1 C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Web.Extensions.dll

It worked on some machines and not on others because some machines had SP1 installed, and others did not. The new version is installed in the GAC, so the web app would always reference the new one. Note that both had the exact same credentials (like assembly version= 3.5.0.0), but different file versions.
 

Eventually, to get things working, we just uninstalled the new one from the GAC. (I guess if we had sufficient time, we'd see how to make the app play nice with the new DLL).  However, this was tricky because we couldn't just do a normal windows uninstall. Running:

Gacutil /uf System.Web.Extensions

Will return:

Assembly could not be uninstalled because it is required by Windows Installer
Number of assemblies uninstalled = 1
Number of failures = 0

This blog explained that that’s essentially a bug, and we can fix it from the registry.

http://blogs.msdn.com/alanshi/archive/2003/12/10/42690.aspx

Go to registry, for this key:

[HKLM\SOFTWARE\Classes\Installer\Assemblies\Global]
for this item:

System.Web.Extensions,version="3.5.0.0",publicKeyToken="31bf3856ad364e35",

processorArchitecture="MSIL",fileVersion="3.5.30729.1",culture="neutral"

and remove its data, so that in the "Edit multi-string" dialogue box, the "Value data" textbox is empty.

Now, you can remove form the GAC by running:

Gacutil /uf System.Web.Extensions

And confirm removal:

Gacutil /l System.Web.Extensions

NOTE – you may need to copy the System.Web.Extensions to your web’s bin folder and recompile the solution in VS.

Lastly, to make all the other websites still work, re-install the old dll:

gacutil /i C:\MyProject\System.Web.Extensions.dll

You should now be able to hit postbacks within Ajax update panels without errors.

You're not a real dev unless you've read this book...

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/youre_not_a_real_dev_unless_youve_read_this_book.htm]

Every now and then some amazing book comes out. And then comes people who insist that "you're not a real developer" unless you've read that book. I was reminded of this while reading reviews on Amazon for some of the hot books out there. While there are core competencies that every dev should know, there are also a lot of fringe topics, and multiple books on the same topic. And while a lot of these things are valuable, I think such an exclusive approach is damaging because it emphasizes not what you know and can apply ("can you write code with design patterns"), but rather what you've read.

 

For example, of course the GoF design patterns book is phenomenal. However, is it really that bad if someone read the C# translation of it instead (Design Patterns in C# by Steven John Metsker), or even skipped the books and went with purely online tutorials? I'd expect a "senior developer" to know what a design pattern is, recognize the buzzwords, and know how to apply them. However, if they got to that point from a different path then "normal" (?), I think that's okay. Part of the problem is that one cannot read it all, so it effectively encourages bluffing - developers buy classic books and display them on their bookshelf like trophies, and are afraid to let on about their shortcomings for fear of being rejected.

 

In short, I think it's far more effective to offer positive criteria like "developers on this team must be fluent in design patterns, automated testing, and writing clean code", as opposed to exclusive criteria like "you must have read book X".