The Web Gambit

Microsoft’s developer story has recently diverged into a tale of two cities.  Martin Fowler and Sam Gentile both recently wrote about it.

On one hand, you have the traditional Mort-focused camp, which focuses on creating drag-and-drop developer tools like GridViews, DataSources, and Typed DataSets.  For this group, the traditional ASP.NET WebForm model appears to be the quickest way to Rapid Application Development.  However, RAD technologies like these tend to break down when they are used on many large scale projects.  This is generally is due to the lack of testability and the inherent bad practices that many new ASP.NET developers pick up when using the tools out of the box.  Without some solid best practices guidance, many ASP.NET projects often fall into a black hole when they reach the testing stage. 

On the other hand, there is a large community of software professionals that utilize Agile development, Open Source tools, and better developer practices while still focusing on the Microsoft platform for their projects.  These developers often balk at Microsoft’s attempts to copy Open Source projects and many find Microsoft’s whole attitude towards open source to be very frustrating.  There has recently been a lot of concern that this group is likely to migrate to the Next Big Thing (whatever that may be) and leave the platform behind all together.

While there are groups within Redmond that attempt to educate developers around some best practices, they aren’t promoted well by Microsoft.  Also they also tend to face some backlash from the larger developer community due to the shaky middle ground they meet between the two sides of the fence.

I am currently focused on developing for the Microsoft platform, but I have no reservations about moving to another platform at some point in my career.  I’ve done it before and I can easily do it again.  My main reason for sticking with .NET has been the amazing friends and colleagues that I’ve met while working with the platform.  The community that has grown around the .NET platform has been it’s biggest strong point for me thus far.  And I think that if the more prominent members of this community start moving to another platform, I will definitely take a look at that platform for myself.

A friend pointed me to this great article
from Business Week talking about Ford’s new CEO, Alan Mullaly, and some of Mullaly’s experiences in trying to change the culture within Ford.  I found one paragraph
that correlated to some of my past experiences as a software developer:

After a couple of hours on the firing line, Ford’s engineers got defensive.
Interrupting the testers, they started airing their side of the story in front
of the new boss. Sensing that the meeting was deteriorating, Mulally says he
handed each one a pad and pen. “You know what? Let’s just listen and take
notes,” he said. The episode was a perfect illustration of what Mulally
considers one of Ford’s major problems: the tendency of employees to rationalize
mistakes instead of fixing them. “We seek to be understood more than we seek to
understand,” he observes.

Developers have all found themselves justifying certain design decisions in an effort to
complete tasks and move on.  This is a natural part of the process of software
development.  But if their focus changes from understanding their users to making their users
accept their design, then their software quality tends to suffer.  It’s a difficult balance to maintain.

I find that following the last two points of the Agile Manifesto would go a long way towards maintaining this balance:

Customer collaboration over contract negotiation

Responding to change over following a plan

What are your strategies for understanding rather than being understood?

Internships are often an exciting experience for students entering many fields.  They can be a great place to learn, network with peers, and develop lasting professional relationships that will be important when first starting a career.  They are also a great way to “test drive” a company that you may want to work for in the future.

Software internships can be especially fun in the right environments as they generally keep you very busy and give Computer Science and Information Systems degree seekers some much needed real world experience.  Many past interns, myself included, have found that their internships really defined the first few years of their career.

To that end, Telligent has created an excellent internship program speared-headed by Jason Alexander.  Jason has dubbed them the Telliterns and has focused them on improving the Reporting features of Community Server.  In addition, Jason has required them to blog daily about their progress, experiences in Telligent’s environment, and whatever else they choose to write about.  I really liked the idea of having them blog instead of collecting weekly status reports or bulleted emails.

Each of the Telliterns has a very different blogging style and I’ve enjoyed reading about their progress as well as all the fun they’re having!  I highly recommend adding their feed to your RSS reader and checking them out.

I generally don’t do book reviews as part of my blog, but after finishing reading Scott Rosenberg’s Dreaming In Code, I can’t resist.  This book is excellent.

I first heard about it from Joel Spolsky and I also heard great things about it from a few attendees at the recent Dallas Code Camp.  So I went over to my nearest bookstore and picked up a copy.  By the way, if you’re looking for it in Barnes and Noble, it’s in the Science section, not the Computer section. 

Dreaming In Code chronicles the development cycle of the open source Personal Information Manager software known as Chandler.  The vast majority of the book covers the Chandler project as a case study and describes team dynamics and design decisions and how both affected the outcome of the project.  It was interesting to see how even an open-source project completely driven by experienced developers and technical people can still have the same pitfalls of scope creep, fuzzy requirements, and poor design choices.

However, I found the best material in Dreaming in Code to be in the chapters where Rosenberg steps away from Chandler and provides insight on the software industry as a whole.  I wanted to post a couple of the more thought provoking excerpts from the book:

From a panel of experts assembled at a conference on software engineering, here are some comments:

"We build systems like the Wright brothers built airplanes — build the whole thing, push it off a cliff, let it crash, and start over again."

"The problems of scale would not be so frightening if we could at least place limits beforehand on the effort and cost required to complete a software task…..There is no theory which enables us to calculate limits on the size, performance or complexity of software.  There is, in many instances, no way to even specify in a logically tight way what the software product is supposed to do or how it is supposed to do it."

"Some people opine that any software system that cannot be completed by some four or five people within a year can never be completed."

These grim perspectives sound familiar, but I left out one detail: This wasn’t a  recent conference.  Every word I have quoted and thousands more like them, can be found in the proceedings of a 1968 summit on software engineering — the first event of its kind, organized by NATO as its member nations started into the eyes of what they had just begun to call "the Software Crisis."

I found this section very thought provoking as it makes it seem like we have not definitively solved some of software development’s biggest issues despite staring them in the face for almost 40 years.

Despite some of the perceived negativity towards software in the book, Rosenberg says blogging is helping to change things:

And yet something extraordinary happened to the software profession over the last decade: Programmers started writing personally, intently, and voluminously, pouring out their inspirations and frustrations, their insights and tips and fears and dreams, on Web sites and in blogs.  It is a process that began in the earliest days of the Internet, on mailing lists and in newsgroup postings.  But it has steadily accelerated and achieved critical mass only since the turn of the millennium and the bursting of the dot-com bubble when a lot of programmers found themselves with extra free time. Not all of this writing is consequential, and not all programmers read it.  Yet it is changing the field — creating, if not a canon of great works of software, at least an informal literature around the day-to-day practice of programming…It is also an open forum in which they can continue to ponder, debate, and redefine the nature of the work they do.

I highly recommend that you pick up a copy of Dreaming In Code today!

Scott Hanselman, noted developer and blogger, recently twittered his blood sugar checks in order to raise awareness of Diabetes. The full transcript of his twitters is now available on his site and it is definitely worth the read to see what an active diabetic goes through on a daily basis.

My paternal grandparents both have Type II Diabetes so I’ve had a mild glimpse of what diabetes care involves. But for a person with Type I Diabetes, like Scott, the monitoring and adjusting of blood sugar levels becomes much more frequent.  Scott’s twittering certainly opened my eyes to the urgency of his cause and I certainly want to do my part to help!

Donate to Team Hanselman today to help fight Diabetes! 

Tim Stall had a great post entitled “Why would someone work for your company?” where he outlined a number of things companies can do to be more attractive for top developer talent without breaking the budget.  I highly recommend reading the entire post, but one point in particular got me thinking about software management.

Good developers have the intrinsic need to grow and learn…Any manager that stifles that for any reason will simply push their best developers away. Such excuses may include: “we don’t have time”, “that’s not in the requirement”, “just do it this way because I said so”, “this approach worked 5 years ago”, “your job is to support the business, not research technology”, etc…

As a developer, how many times have you heard those last few phrases? I certainly have heard them many times from several managers in all different industries.  Most software managers would prefer to take approaches which they have personally seen work rather than attempt anything new and unproven. 

This view often seems short-sighted, as most seasoned developers know that every software project can have dramatically different requirements and technical environments.  A good software manager has to understand the capabilities of both the available personnel and the technical environment to determine the best approach to the business problem. 

I have seen many projects fail because the management decided to build a solution based on a previously successful approach but used a different set of programmers and a completely different technical environment.  So by attempting to be less risky by using a tried and true approach, the project actually has created more inherent risk by forcing both developers and technology down a path to which it may not be suitable.

It’s my opinion that if software management is willing to re-evaluate their personnel and their technical environment before embarking on a new project, they should also be equally willing to try a new approach or methodology as well.

Well after being issued a challenge by Jayson Knight to switch to Community Server after my job change announcement, I can finally say that my migration is complete!  Here is what I had to do in order to get my blog migrated over from Wordpress.com to a self-hosted Community Server 2007 installation.

1. Find a decent web host!  I went with Server Intellect after it was recommended by both Jason Alexander and Tim Rayburn.
2. Install CS 2007 on my new host.  Initially I tried the CS 2007 web install but it simply wasn’t working so the guys at Server Intellect offered to install it for me.  This was both good and bad.
3. Migrate my old blog posts. This was the most arduous piece of it.  For this I did the following:

• Exported my Wordpress.com posts as an XML file in Wordpress’s extended RSS format.
• Created a temporary self-hosted Wordpress installation on my old crappy PHP-only webhost using one of their install scripts.
• Used Robert McLaw’s Wordpress to BlogML export tool (which is just a PHP file that works only with a self-hosted Wordpress installation) and export my posts as a BlogML file.
• Massaged the data in the BlogML file because it was in BlogML 1.0 and would not validate against BlogML 2.0’s schema.
• Took the completed BlogML 2.0 data file and merged it into CS 2007 using Keyvan Nayyeri’s BlogML 2.0 to CS2007 converter.

Now that all of my posts were migrated, I still had to do a few manual things in order to completely detach myself from the Wordpress.com blog:

• Edit all of the URL’s that cross linked between blog posts so that they pointed to the newer migrated posts.
• Copy over all the blog post images that were saved onto Wordpress.com and move them into my CS 2007’s blog files directory and update all blog entry references to them.
• Update my FeedBurner feed to point to the new feed coming out of CS 2007.

Once all of that was done, I started playing with the styles and ended up customizing one of the built in dark themes to look more like my wordpress’s blog style.  I found the Chameleon theme engine within CS 2007 to be very intuitive and properly designed.  Mimicking my old Wordpress theme was extremely simple and I had something very close to the same look within half a day!

The last thing I had to deal with was a strange bug that was causing all of the Javascript calls to fail on my CS install.  After digging around to see if this was a common problem and making no headway, I put in a post over at CommunityServer.org asking for help. Keyvan responded immediately and asked if I had all my Javascript files transferred over in the installation. Of course this would be the last thing I’d have thought to check.

After snooping around in FTP I realized that not a single .JS file had been transferred over with the CS install done by Server Intellect.  This dumbfounded me, as it meant I’d gotten this far with my CS 2007 install without having any working Javascript!  Most applications I’ve used (and written) won’t get very far at all if you turn off Javascript or don’t have it installed properly.  Very impressive.

So thats it, update your bookmarks to point to webgambit.com!  Unfortunately any older links floating around the net that point to my old blog posts will soon point to dead links.  This is unfortunate, as I would like to have had a way to forward the posts, but it doesn’t look like Wordpress.com will allow me to do that. I’ll soon change the old blog to have only one active post pointing it here.  If you’ve linked to any of my old blog posts anywhere on your site, please update your links if you can.

For those reading over RSS, make sure you subscribe to the FeedBurner version of my feed as the old Wordpress.com RSS feed will no longer be updated.  If you’ve subscribed to this blog through FeedBurner as I asked, you don’t have to change a thing!

Joe Ocampo had a great post where he gave his checklist for an effective Agile Development Manager.  I think that many of the points he makes are very relevant for even non-Agile development managers too.  And while I agree with most of what Joe is saying, there are a few areas that I want to expand on.

1. You have to be a developer yourself.  If you don’t know how to code don’t manage developers period!!!!  And knowing COBOL doesn’t count!

I agree with this wholeheartedly.  However I would expand this to say that while a lead developer should be up to date with their skills to provide guidance to the other developers, the lead should also recognize that the others may find a better technique for a particular area of the project.  The lead should be willing to try the new technique rather than only use familiar techniques.

2. You have to manage the team not the individuals.  Think of yourself more as a coach not a manager.  Maximize your assets by understanding your team’s weakness and strengths.

3. If you have mediocre programmers (first off yikes!) second as long as they show a willingness to learn, paired programming is the key to success for bringing the juniors up to par with the seniors.

Let’s face it, it’s not always realistic to fill a team with Spartan Developers.  Since teams always have varying skill sets, it is very important to quickly assess where all the team members stand to determine which tasks are most appropriate for them.  All too often I’ve seen situations where a developer is assigned a task that is beyond their skill set and they can’t complete it in time.  Depending on the task’s visibility, such things can linger for weeks before it becomes apparent that the developer should have been given some help to complete it.  While the pair programming method can help alleviate such issues greatly, a good lead should take the time to recognize the team’s talents and make sure tasks are assigned accordingly in the first place.

4. Empowerment, allow EVERYONE to take ownership of stories and task.  If a junior wants to take on a story or task let him/her role with it.  Your TDD practices along with the pressure from their peers will make certain it is done correctly.

Completely agree with this point. A good process should allow plenty of opportunity for individuals to take ownership of difference pieces of the project.  Most teams with a good process are also very good about policing themselves. E.G.,  I’ve seen a lot of interest techniques on how to punish the person who broke the build.

5. Embrace the fact that your team need to understand their goals!  What they are playing for?  What is the goal for the week (Velocity, Stories)?

This is possibly the most important point on the checklist.  A team cannot work well if everyone doesn’t understand the big picture and the business problem that is being solved by the project.  Also it should be easy for any team member to map every one of their tasks correlates to a relevant business problem.  If individual tasks do not easily map to an understood business problem, then the development process is broken and should be re-evaluated.

6. They need a way to measure and understand if it is first and ten or fourth and twenty?

Hammering on a set of tasks with no end in sight can de-motivate even the most productive and task-oriented developer.  Everyone needs consistently measurable progress. 

7. Coach them every day!

Daily feedback is something that Agile techniques like SCRUM emphasize a lot.  The key thing to understand here is that coaching doesn’t always have to be at the individual level.  A simple email to the whole team saying “Good job on that last sprint!” might be all that’s needed to effectively fulfill your coaching quota for the day.

8. Get rid of your heroes or code hogs!!!!

This is the one point where I don’t agree with Joe.  If one of your developers is being a code hog or causing dissension within your team, it’s because you aren’t sufficiently challenging or motivating them.  Also if you aren’t respecting their opinion then you are only feeding the fire of team dissension.  Address it by understanding their goals/motivations and utilizing them more effectively.  Dumping your Hero is the last thing you want to do.  The simplest way to deal with a Hero is to give them ownership of a particular area and respect their opinion when its warranted. And if you find reason to disagree with them, clarify your points rather than simply pulling rank.

I still find it amazing how many people mistook the context of my original response to Dave Laribee’s ALT.NET post. It started with a few blogs and I tried addressing it via commenting on those posts but I’m still getting comments on my blog about it so I think it’s time I just set the record straight here.

The intent of my original post was not to push one tool over another, but merely point out that ALT.NET developers likely understood concepts such as Unit Testing, Automated builds, ORM, and MVP/MVC design before the Microsoft implementations of these concepts became available. Whether they picked up a specific tool in the process may have been a side effect of learning the concept through the use of a working and practical implementation. In no way did I intend to show favoritism toward any tool over another.

Perhaps it was my poor choice of words that incited this, but I think I’ve made it sufficiently clear that my post was not intended to turn the ALT.NET discussion into a tools-based religious debate.

I had been sitting on this news until things were more finalized, but now I think it’s time to let the cat out of the bag.  I have recently accepted a position with Telligent as a Software Development Engineer in their Services division!

Telligent is well known for their community-based platform, Community Server. For those who haven’t heard of it, Community Server is the premier platform written in .NET for blogging, forums, file, and photo sharing and it powers many Community-based web sites such as the ASP.NET Forums, MSNBC Blogs, and many others.

As an SDE for the Services team, I will be working on projects for Telligent’s clients doing both custom development as well as customization of Community Server to enable clients to engage their customers more directly through sites that help build communities rather than solely push out content. 

I think this type of customer interaction will become more important as companies try to differentiate themselves by opening a more direct dialogue with their customers.  Companies utilizing this approach are proving to be more successful than those companies that rely solely on market indicators and statistics to determine what their customers really want.  Telligent’s CEO, Rob Howard, seemed to echo the same sentiment as he spoke about his vision for Telligent recently on DotNetRocks.

I want thank both Jason Alexander, Telligent’s CTO, and Scott Dockendorf, Telligent’s Director of Services, for providing me with this opportunity and making the hiring process as smooth as possible. 

Jason told me that my blog was one of the reasons he reached out to me.  You never know where your blog can lead you.  So if you’re a developer looking to get noticed, ditch your flair, and start blogging!