Why Don’t People Take Sick Days?

Leave a reply

Last night, I was feeling a cold coming on. I felt a little sweaty and I kept blowing my nose. But I convinced myself that, if I got enough sleep and kept popping the Vitamin C, I’d be fine.

This morning, I got up and was totally congested. After a few minutes of standing upright and blowing my nose, the congestion faded. I felt tired and run-down, but I convinced myself that it was just from waking up. I popped some cold medicine (the non-drowsy stuff) to take care of the symptoms and went into work.

Ninety minutes later, I decided to go home, rest and recover. I felt drowsy from the non-drowsy medicine; I was tired and run-down, and kept blowing my nose; and I could not focus on any work. Why didn’t I listen to my body when it told me to stay home and rest?? Why did I feel like I needed to come into work today?

I felt it was ironic that I had read this Scrum cartoon the night before…

A Distinction Between Tiers and Layers

Leave a reply

Ted Neward wrote a good article on MSDN about distinguishing layers and tiers in system design. This is to be his first article in a series of articles about Pragmatic Architecture.

The article has some pretty good points about the over-use of n-tier architecture, which I will admit to using more often than necessary. His article goes on to say that a separation of concerns is not itself a bad idea, but rather, the popular implementation of using separate assemblies spread over multiple machines (for example, a client’s machine, an application server, a database, etc.)

A previous project I worked on implemented a rich-client system containing a user interface executable, a few too many business layer DLLs, and a separate data access layer DLL — all installed on the client’s machine. At the time, I was graying the distinctions between layers and tiers. While my design had loose coupling, I was taking a significant performance hit by using several separate DLLs to separate the concerns instead of relying solely on the .NET namespaces.

The point of Ted’s article is to show that, in a design like the one described above, it is better to use logical layering (layers) rather than physical layering (tiers); however, in other designs, the use of n-tier architectures may be preferable. This is a good concept to remember, as it can save time and effort later down the road during performance tuning.

A Comic about a Chicken and a Pig

Leave a reply

A comic about Scrum? What a great idea! It combines the humor of all the wrong ways Scrum is used with the insightful commentary and explanation by the author on why the concept satired by the comic is wrong, and how to do it right.

For those of you unfamiliar with Scrum, you may not immediately respect the irony that the two main characters are a Chickin and a Pig. Maybe this will help.

Regardless, this web site is for Agilist/Scrum folks the way the Daily WTF is for IT people in general.

State Management in ASP.NET 2.0

Leave a reply

I found this article from MSDN to be a good introductory resource for working with State Management in ASP.NET 2.0. Since I’ve been developing WinForms apps for over a year now, and haven’t done any ASP.NET since 2004, I found this to be a good refresher.

This is a good introductory article for WinForms developers moving into Web Application development, especially those working in 3(+)-tier architectures since you now have to do something with your business objects in the event that a postback occurs.

The Mighty (and Forgotten) Iteration Zero

Leave a reply

I recently started a new project, developing a fairly simple data-driven web application. The project itself consisted of a handful of Use Cases, a couple web forms and a domain model containing less than a dozen domain concepts.

While it was my first time working with version 2.0 of ASP.NET, I was also trying out two new metrics, which a friend suggested: A Burndown Chart and a Velocity Chart. I’d also chosen 1-week iterations to give me the best feedback on my progress, as my initial estimate put the project at 6-8 weeks.

For my first iteration, I selected a small, core piece of functionality to implement. I knew in the back of my mind that I’d be writing some architectural-centric code for my different tiers, as well as setting up my web project and database permissions.

TMI? Keep reading – I do have a point coming up.

So how did I perform? Well, I was able to set up my web project; my database users and roles were created; and I had a good portion of my UI and business tier implemented. But, according to my metrics, I had done absolutely nothing. Why is that? First, I was only measuring the points of my chosen Use Cases. Second, I can only account for points if I have 100% completed the feature, period. No if’s, and’s or but’s.

So, how do I account for all of the work I’ve done so that my business users and management don’t think I’ve done nothing the whole iteration? I asked my friend, who suggested I implement a zeroeth iteration. That’s right – Iteration 0.

Once I stopped laughing, realizing that he was totally serious, I considered it and figured that it made a lot of sense. The first iteration of a project is partly a “Setup” iteration. While I’m not implementing anything of value for the business, I am working on tasks necessary to complete future iterations.

So, if you’re starting out a project and trying an iterative approach, keep in mind the mighty Iteration Zero. It could save your life, or at least some explanation time to your boss and/or business users.