The Web Gambit

Thoughts on Web Development

Monthly Archives: June 2007

Things I learned about Software in College

Dare Obasanjo started a thread listing things he learned about software while in college and Scott Hanselman extended it by adding three more things he learned in college and three things he learned outside of college. 

Both bloggers had some great points and I recommend reading both posts as well as the comments.  But I thought I would chime in to the discussion with my own list.

Things I Learned about Software in College

  1. If getting things working is the primary goal, most programming assignments can be completed by one person in a reasonable amount of time.
  2. Reaching the “ah ha!” moment in programming is very important.  Until you reach that moment, every programming assignment will be marginally tougher.
  3. Don’t work on assignments with the smartest person in the room.  Immediate learning by imitation doesn’t work too well in software.   Find your own way that works first, and then improve your style by emulating others.

Things I learned about Software after College

  1. Most good software is built by teams, not individuals.  If you don’t understand this point, you’ll always be a second-rate developer.  No matter how well you hack things together.
  2. Being a software professional truly means being a lifelong learner.  Chances are the tech you cut your teeth on in college will be obsolete soon after graduation.
  3. True happiness as a software developer lies in liking those who you work with, not liking those who you work for.  Some of my best work experiences were great because of the amazing colleagues I had a chance to work with, not the company or brands I worked for.
Advertisements

Silverlight on Linux in 21 Days

After just recently promising to bring Microsoft’s Silverlight to Linux by years end, Miguel De Icaza, the project leader for Mono, has ported significant portions of Silverlight in only 21 days.  He chronicled this effort in a recent blog post.

The past 21 days have been some of the most intense hacking days that I have ever had and the same goes for my team that worked 12 to 16 hours per day every single day –including weekends– to implement Silverlight for Linux in record time. We call this effort Moonlight.

Regardless of what you may think of the viability or futility of the effort, it is awe-inspiring to see a group of developers be so motivated to work towards a goal.  To go through this level of effort despite being disliked by both sides shows a real passion that most developers lack.  Kudos to Miguel and the Mono Team for this very significant achievement.

Silverlight has been on the tip of a few tongues at Telligent so it’s great to see that our clients won’t lose even a small percentage of their users if we building it into our products.

The Economics of Disposable Code

Nick Malik wrote a post entitled “Mort and the Economics of Unmaintainable Code” where he espoused the belief that re-writing code can be more economical than writing good, maintainable code in the first place.

Rather than look at “making code maintainable,” what if we look at making code free.  Why do we need to maintain code?  Because code is expensive to write.  Therefore, it is currently cheaper to fix it than rewrite it.  On the other hand, what if code were cheap, or free?  What if it were cheaper to write it than maintain it?  Then we would never maintain it.  We’d write it from scratch every time.

The post, like others stems from the discussion around Microsoft promoting drag-and-drop controls for Rapid Application Development in .NET.

My concern with this line of thinking is that it assumes that the code only accomplishes one thing: making the application function.

The reality is quite different.  The code very often provides much more than pure functionality.  Often the code is the only maintained artifact that fully describes the current business process or workflow supported by the application.  These days most developers aren’t creating complex UML diagrams or relying on elaborate comments.  It has been my experience that when requirements and business processes change, the code is the first and last thing to be changed.  When looking at most software, rarely do you find supporting documentation and other artifacts that are maintained as well as the code.

Code drives business value far more than most other artifacts and is thus maintained far better than documentation.  While this may not be true in every organization, it has been my experience that any organization that finds itself rewriting code will typically rewrite significant parts of their business processes as well.

Given the choice between rewriting a business process and writing maintainable code in the first place, I think it’s clear which is the more economical approach.

My first week at Telligent

A few friends and colleagues have asked me how my first week of Telligent went.  And I assume some of my readers may be wondering the same thing.

In a nutshell, my first week at Telligent was excellent.  I’ve been given some new responsibilities, a larger role at a major Dallas area client, and some exciting career goals over the next few months.  And that has just been in the first week!

My first project at Telligent will be my first foray into consulting engagement management and it will allow me to really take ownership of a consulting engagement.  While I was at Deloitte and during my stint as an independent consultant, I worked closely with engagement managers and client managers so I’m very familiar with the process.  I also have a amazing mentor in my good friend and former supervisor, Manu Puri, who has been very helpful in advising me on some of the engagement management approaches that have worked for him in the past.

The engagement also opens up some great opportunities for Telligent as there is a lot of potential for future projects with this client that may possibly build some excellent qualifications for Telligent around new technologies like CardSpace and Windows Presentation Foundation.  Being involved in such projects would do a lot for my personal goals as well so I’m eager to see what can be done.

As you might have noticed, Telligent has done a lot to help me scratch my Consulting Itch, something that I haven’t scratched in a while.  I’ve been scratching my Coding Itch for the past year, so it’s been a nice change of pace for the short term.  However, I don’t plan on ignoring my Coding Itch for too long either!

My take on Telligent as a whole is that it is a great place to work and has some very smart people.  The environment is very welcoming and easy going, but not truly relaxed.  Everyone works extremely hard and is very motivated to help the company succeed.  However, they do take the time to have some fun and not take themselves too seriously.  Additionally, the company is very family oriented as well, which makes long terms prospects much more viable than with many other technology companies.

I had initially been a bit concerned that I’d have some difficulty getting accustomed to Telligent’s startup-like environment.  Especially after working primarily in Hierarchical, Corporate environments.  But I think I took to it like a fish to water and I immediately felt very comfortable. 

At first, I was a bit intimidated working for people like Rob Howard, who I still see as something of a .NET Demigod.  But I realized very quickly that despite having many brilliant people, Telligent still has its challenges like any other company and plenty of opportunity for motivated individuals to excel and make it more successful.  I was also very impressed by the modest brilliance I’ve seen in the people I’ve been working with and I truly appreciated their approachability.  There are very few closed doors in the Telligent hallways and most people are eager to lend a helping hand for those who need it.

To sum it up, it was a great first week and I’m looking forward to a long and rewarding career with Telligent.  They are still hiring quite a bit, so if you’re interested, be sure to apply!

DDNUG and the After Party

Last night, my good friend Dave O’Hara gave an excellent presentation on Automated Unit Testing with the .NET framework to the Dallas .NET User Group.

Dave covered the tools available to write unit tests in .NET including NUnit and others.  He also covered Mock Objects and Dependency Injection, two topics that I have been trying to grok recently.  Dave’s talk focused on using RhinoMocks for the DI and Mocking.  It was a lot to cover in a short amount of time, but it definitely put me on the right track to understand some very advanced topics. 

Afterwards, a bunch of us got together in Grapevine for drinks and food to discuss tech topics as well as give Dave some valuable feedback about his presentation.  We also discussed some possible initiatives for the Dallas developer community and hoisted a few congratulatory brews for a few upcoming family expansions.

All in all it was a great time and I highly recommend that if you get a chance to come down for a DDNUG meeting, you should block out an extra hour or two to come hang out with “Rayburn’s 8” (as our little group is tentatively called).

Dave will be presenting his topic again at the North Dallas .NET User group on Wednesday, August 1, 2007.  If you’re looking to learn about Unit Testing in .NET and you enjoy learning from an energetic and enthusiastic speaker, make the time to attend Dave’s talk. 

Business People should not Control Code

Scott Bellware recently ranted about how there seems to be no end to the number of vendors promising the Holy Grail that allows Business people to take responsibility for changes to their business processes and move them into production code.

Creating software isn’t hard.  Making changes to it is hard.  And making changes to software inevitably means verifying that those changes actually work, and that the changes to one part of the system hasn’t caused another part of the system to behave unpredictably.

I couldn’t agree more. I mentioned this very point in my discussion around Business Rules Engines.

Recently I was discussing the failure of a past project which relied very heavily on a BRE and one of their biggest pain points was maintaining it.  The Business Analysts were not trained to write test cases for their business rules and routinely broke one set of rules with changes made to another set. 

Things got even worse because an end user generally had no clue why a particular page in the application was malfunctioning and would report a system bug.  Due to a very poor integration with the rules engine, a programmer would be required to reproduce the bug and see that the rules engine was throwing cryptic (and not handled) error messages which affected the page.  After spending all this time in code, the programmer would often find that the Business Analysts broke the code and would have to make them roll back all of their changes to fix the bug. 

So in trying to reduce the need for programmers by using a BRE, the project actually gave the programmers more work because they were responsible for diagnosing bugs that were not in their control to create or fix!

More Lead Developer tips

You can never have enough useful tips on becoming a better lead developer.

From Roy Osherove, there are some great ones in this list.

To this list I would add the following:

  • Be open to ideas and approaches from your team members, regardless of their seniority.  Don’t dismiss a great idea because it came from an intern or fresh graduate just getting their feet wet.  Even if an approach is fundamentally flawed, don’t kill a person’s spirit by making them feel stupid for even suggesting it.
  • Don’t overly criticize a teammate’s work in earshot of other teammates. This is especially important when doing regular test and code reviews.
  • Show your team honest appreciation when they do a good job.  A little praise goes a long way in keeping a person motivated and productive.
  • Make an effort to understand each team member’s career goals and keep them in mind when assigning out the work.  If someone aspires to be a SQL demigod, try not to force them to write a lot of HTML/CSS/Javascript.

Plugging back in

I took a week off before starting my new job and I decided it would be a good time to try a little experiment.  I decided to unplug myself from my computer.

Since last Friday, I did the following:

  • Stayed off instant messengers (no Googletalk or MSN)
  • Limited checking email to once a day
  • Twittered maximum once a day
  • Ignored my RSS feeds completely
  • Posted no blog updates

Basically I kept my computer time up to a maximum of 10 minutes per day for an entire week.  I initially started out by traveling to visit my parents and not opening my laptop at all (even though I took it with me).  When I got home, I resisted the urge to setup my laptop (it stayed in its bag until this morning).  By forcing myself to use my aging desktop, I was able to limit my computer time significantly.

At first I thought I would go nuts not checking my email/twitter/RSS/IMs, but after 2 days I found the whole experience to be quite liberating.

So what did I do during this week of no computer time?  I read a few good books, played some xbox, got LASIK, and spent quality time with family.

Now I’ve got a lot of catching up to do, but I had to prove to myself that if the Internet was to suddenly go dark, I could still maintain my sanity :)