Staying with the Fire Hose

At the recent Ann Arbor Day of .Net, my colleague David Giard arranged an excellent panel discussion with Jim Holmes, Mike Eaton, Jay Harris, Patrick Steele, and Jason Follas, about keeping current with the stream of constantly evolving technology with which we work (aka the Fire Hose). I felt this was one of the best sessions of the day, the audience was very engaged with the panel. It definitely ended too soon. *Update* David Giard posted a video of the discussion on his Technology and Friends webcast.

One of the discussion points revolved around training. I think a couple points were pretty clear from the discussion:

  1. Companies don’t provide enough or the right training
  2. You own your career, it’s up to you to get the training you need.

One of the discussion points that I wanted to contribute, was that the existence of Day of .Net is partly driven as a reaction by the community to the two points above. We attend these conferences to learn (among other things) just enough about new technologies so we can effectively evaluate them and see if they fit into our day-to-day jobs or personal interests. Traditional training methods (books, classroom training, CTBs) seem to be falling further and further behind as the fire hose continues to flow faster and faster. We are at the conference to get some of the training we need, because it’s not available any other way.

Technical Books

For me, books have always been part of my learning, but more and more they are falling short. Technology is changing faster than publishers can respond. More often than not the book I need isn’t going to be published for a while. Even today (May 2010), look at the number of new developer technologies that are hot in my circles:

  • Silverlight 4
  • Windows Azure
  • Windows Phone 7
  • Android
  • SharePoint 2010
  • .Net 4.0

These are by no means niche technologies. You would be hard pressed to find many books published on them (maybe some around beta releases, those get stale fast and are often of dubious quality due to the rushed nature of the title). I completely understand the lag time, but I think the publishers need to step up and start paying authors as full-time employees so they can commit full time to a book and get it released sooner. Typically book authors are doing this on the side, I am sure that slows down time to market. There are some Microsoft technologies, like Commerce Server, that haven’t seen a new book since 2002. Arguably that’s a much more niche technology (and certainly not as popular as SharePoint for instance), but if a company as large as Microsoft is investing money to develop the product, they have users of the software so there must be some kind of market for those books.

I know lots of folks don’t work on the cutting edge (I spoke to a group of VB6 developers yesterday that didn’t even have Visual Studio installed), so this is less of a problem for them. As a consultant, this is a constant problem for me. Maybe I am am the minority and there isn’t as much market for these books so early? That’s hard for me to say. Either way, I know the publishers are losing my money, because I end up digging up blog posts and finding online articles to meet my need long before the book hits the shelves for me to purchase it.

Posted: Thursday, May 27, 2010 9:48:25 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
Programming | Reviews | Speaking | Tools

Loveletter Worm

Yesterday was the tenth anniversary of the Loveletter (ILOVEYOU) worm. This was the first real virus/worm that I ever experienced that actually took down a mail server. It was also an early, widespread, damaging worm. At the time, I was in my colleague’s office (he was the network guy), and he got an email. He looked at me and said “Why would Gary send me a message saying ‘I Love You’”? A few seconds and 5 similar messages later it dawned on him what was going on, he ran down the hall to the server room and hard-powered off the Exchange Server. Later we determined only 79 accounts got the email before he stopped it. It still took two days to get the mess cleaned up.

What really struck me about this was the code of the worm. I was doing classic ASP programming at the time, so I was pretty conversant with VBScript. I printed it off the code to check it out (see a description of what the code does). I was really struck by the fact that I understood what they were doing, and it didn’t even seem that hard. It was a real watershed moment for me as a developer, I had reached a point of understanding with that technology; it validated my progress as a developer.

The Love Bug: A Retrospect

Posted: Wednesday, May 05, 2010 10:37:35 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
None | Programming

Link Love

I’ve run across some great blog posts lately, and decided I needed to share and keep track of them:

Cultivate Teams, Not Ideas at Coding Horror. I am totally with Jeff on this one, I learned this a while ago. I’ve taken my last two jobs based on the quality of people working there, not the work that they were doing. I love the quote:

In software development, execution is staying on top of all the tiny details that make up your app. If you're not constantly obsessing over every aspect of your application, relentlessly polishing and improving every little part of it -- no matter how trivial -- you're not executing. At least, not well.

I want to work with folks that feel this way about the work they do. Quality matters, and even more in my profession as a consultant. Quality work today gets me more work tomorrow, I can’t afford not to write top notch code and deliver quality solutions. Few things really upset me as much as shoddy work, whether out of ignorance or laziness. If you are a professional, there is no excuse for either one.

My co-worker David Giard (the host of Technology and Friends) wrote a very insightful post about being a programmer, It's not easy, so don't pretend it is. I agree with Dave 100% that we are undervaluing what value we provide with our skills. I pledge along with Dave to take the word “easy” out of my vocabulary when talking about the work I do. As someone who has to estimate work, I understand the complexity of what we do and struggle to communicate that to clients, and I think what Dave describes contributes significantly to that problem. End users/clients can’t easily see the complexity of what we do (“it’s just a form”), and can’t understand that adding “one extra feature” may actually triple the complexity of the solution, because our long-term message to them has been “it’s easy”.  This actually relates to what Jeff said about teams as well. Good teams care about the quality of their work, so don’t minimize what you do to your clients or users, show them the quality of what you can do.

Lastly, I want to point out the terrific blog written by an ex-coworker of mine, Bob Kreha. While Bob does not write about technical topics per se, his observations about management really strike home as a person who is frequently managed (aren’t we all?). I particularly enjoy his insights into leadership, since I view myself as more a of a leader than manager, even though I technically may be a manager. His post BFF’s has a quote that strikes a particular chord with me, talking about a manager’s relationship with his subordinates:

So if you want nirvana, start with commitment, fairness, shared credit, transparency and vision.  You might be surprised where you end up…

I can’t tell you how many times I struggle with my job because the management above me is not clear enough on where the collective “we” should be going. I frequently think “help me help you” when I am dealing with management. Everyone has an agenda, some folks more than others, but really I wouldn’t be working at a company if I didn’t think we were working toward the same goals. But with management it often seems like they are not on my side over some of the most petty issues. Really, due to a lack of transparency and shared vision, I think it’s petty when really it may not be, I just don’t understand the scope of the issue (or other pressures from management higher up) because no one is sharing. When it feels like maybe we are not on the same team, quite possibly someone is on the wrong team. The bottom line is, tell me where we need to go, I’ll help us get there. If you don’t tell me, I can’t help.

I’ve been pretty dark from blogging for a while, it’s good to get back into the swing of things. I’ll try to follow up with a more technical post soon.

Posted: Thursday, April 01, 2010 10:48:41 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
Programming | Reviews

eBooks on CodePlex

Wriju has a gread roundup of eBooks/guidance available on CodePlex.

Posted: Friday, January 09, 2009 4:01:49 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
.Net 2.0 | .Net 3.0 | .Net 3.5 | Programming | TFS | WCF

Laws from DDJ

Got my new November Dr. Dobbs issue today. The back column "Swaine's Flames" has reminded me of some programming "laws" that I have seen before. I have added my own corollaries for each:

Kernighan's Law: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

My corollary: "The developer who's code that you inherit believed they were twice as smart as they really are."

Eagleson's Law: "Any code of your own that you haven't looked at for six or more months might as well have been written by someone else."

My corollary: "You can recognize that you have written code to solve a particular problem but will be unable to locate the specific instance you recall."

Posted: Tuesday, October 02, 2007 4:50:05 AM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
Programming

Design with Users In Mind

We all spend lots of time delving into the technical aspects of our work, but don't forget who we are creating all these wonderful apps for. You need to design your apps to work for the users, not create apps that the users need to work to use.

Required Reading: Four Modes of Seeking Information and How to Design for Them

Posted: Wednesday, January 31, 2007 11:09:29 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
ASP.NET | Programming | Winforms

Exception Handling - Too Much 'Faith'

A recent post by Lamont Harrington asks about the proper methods for exception handling:

“Should exceptions be bubbled up the call stack and be unwound by a “global“ exception handling layer and logged appropriately, or should some form of exception handling happen at the point of code execution? “

I think a proper design does both. There are cases where the exception can be handled in the procedure where it occurs. Good defensive coding trys to identify as many of those cases as possible and handle them (Actually, good requirements and design should identify many of these situations). Obviously, you cannot foresee all circumstances so the “global” handling is necessary as well. Personally, I don't like to repeatedly re-throw an exception up the call stack because the procedures don't handle it specifically, I would rather let it bubble up on its own and handle it at the end. Re-throwing tends to bury the real source of the error when you are trying to debug a problem in a multi-tier application.

I have to add a plug for the Exception Managment application block. It has been very good to me so far.

Posted: Tuesday, August 17, 2004 2:26:24 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
Programming

Business Objects Dead?

There a fascinating discussion going on at Tim Sneath's blog about the functionality of the business layer moving to compiled stored procedures in Yukon. At least in my project, we have been doing that very thing and struggled with the n-Tier issue as a result. In our case, the database is Oracle 8i, and the application is/was ASP, which we are now converting to .Net. We have some very complex business logic encapsulated in PL/SQL stored procedures. There were two concrete reasons for the decision:

  1. The amount of data that would need to be transferred was huge.
  2. Oracle is more efficient than ASP code at many of the operations involved.

With ADO.Net, some of the ineffieciency may be addressed, but the database is designed for efficiency at certain operations that ADO.Net won't be able to match.

We did not need to approach this from a scalability issue, as the app receives hundreds of hits per hour, not thousands or more. I still think it will scale OK as your business objects will have much shorter life spans and you can still pool and queue database connection objects if needed due to long-running stored procedures.

Posted: Monday, October 06, 2003 12:57:15 PM (Eastern Standard Time, UTC-05:00)  #    Comments - Trackback
Programming