Along the Way…

Archive for the ‘Software Development’ Category

Image by Wonderlane via Flickr

I was sitting in my cubicle, struggling with SharePoint’s stupid use of completely non-standard date formats (would it be so difficult for Microsoft to make sure their own DateTime.Parse() method can parse whatever format they decide to use?), when I heard my name mentioned in conversation going on nearby. Of course, my ears pricked up, and I overheard a snippet of discussion about the estimating process I introduced on a recent project.

The one person in the conversation who had any first-hand knowledge of my project was, essentially, mocking my approach by pointing out all of the details I had overlooked in my initial estimates. My first reaction to hearing this was to be a little hurt that someone I thought had understood what I was doing, and agreed with my approach, was so quick to “throw me under the bus,” so to speak. However, the more I thought about it, the more I realized that there were two different issues at play, here.

First, it seems this person did not really understand what I was doing; he apparently had agreed with my approach because I was using all the appropriate agile buzzwords, and his primary purpose in hiring me onto the team was to introduce some sense of agile process to the project. I really only have myself to blame for his misunderstanding about what was happening.

Secondly, he must not have realized that he didn’t really understand what was going on. If he did, then it seems he jumped the gun a bit, by not offering me the benefit of the doubt, that I actually did know what I was doing!

So, what was going on that caused this confusion? Well, because our company culture isn’t really very conducive to a truly agile approach to software development, I made it my highest priority to engender a sense of trust in the developers themselves. That seemed to be a an achievable goal, so I began all of my estimations with the assumption that individual developers would voluntarily accept specific tasks and provide their own, binding estimate of the effort required.

Accompanying such an approach, I wanted to leave as much of the actual design of the solutions to the developer, as possible. This is where, I believe, the conversation I overheard made its most erroneous assumption. They assumed that my estimates were based on a comprehensive design of the software being constructed, rather than an extremely broad brush view of the primary components I expected to be needed. This means that much of the infrastructure was left undesigned, as I trust the senior level developers to identify and design the infrastructure needs of the business solution.

Of course, it’s also entirely possible that what I overheard was not even about me! There are a couple of other “Kens” in my building, and you really have to give the benefit of the doubt to people when you’re just eavesdropping on a part of a conversation!

This is a great description of *why* REST is so much better (at least, IMO)…

Two Cardinal Sins of REST API Design

Using a thing for its originally intended, “organic” purpose is ALWAYS better, in my experience, so it’s helpful to think about the central addressing scheme for the web and always keep in mind what it means!

U = Uniform (consistent to a standard… just good common sense)
R = Resource (this is a THING. we are addressing something, a noun)
I = Identifier (the unique identity of this thing)
L = Locator (the current residence for this thing)

Note that URI’s should NEVER change for a specific instance of this thing. URLs may change… though, hopefully, not frequently, as moving is always a p-i-a.

Now, following my own best practice of keeping the “things” in my solution as close to the original, organic “things” in my business problem space, take a look at the resource being addressed in a URI. Go pull a random URI for any of the code you’re working on today.

Is the URI pointing to a noun? Does the name of that noun exist within your business?

For example, if I go to the line of business and ask them to tell me what sorts of operations they typically perform on a “CustomerService”, what will they say? Nine times out of ten, they’re going to say, “Customer Service doesn’t have any operations… it’s one of the products we deliver to our customers!”

The resource isn’t a Service. Services are just verbs that have been crammed into a noun. SOA might be great for the Enterprise, but that’s a different topic. Individual applications should NOT be designed by the same design principles of SOA, that we use for the enterprise.

Change that previously mentioned “CustomerService” resource into a “Customer” resource and think about the difference it makes… especially, as you read this article.

This simple change will force you to be consistent about the canonical representation of your business objects, realign your functionality (i.e., operations) to your business objects (this alone, will either increase the business value of your solution, or will highlight the gaps in your object model), and make it easier to be consistent from one resource to the next.

Any thoughts or comments?

There are so many really great webcasts, online, these days, that it’s difficult to know which ones to invest your precious time in viewing. Wouldn’t it be great if there were a “Cliff Notes” service that reviewed these valuable sources if knowledge, so we could avoid wasting time without missing the nuggets?

There is! Tim Bauer watches webcasts for you, and publishes his review online, so you know which ones to watch. Based on the name of his blog, I presume that he’s incorporated these webcasts into his daily fitness routine; probably watching them while he’s jogging on a treadmill or something.

If there’s a particular webcast you’re interested in, you can even submit it to his queue, so he’ll review it for you!

If you’re collecting your RSS feeds in Outlook, like I am, it’s pretty simple to set up some rules and custom views to automatically get reminded to watch the best webcasts:

To get the automatic flagging (which adds the “Definitely Watch This” webcasts to your task list), you create a rule that looks like this:

To get the color coding, you can use the Automatic Formatting feature of Outlook views. To do this, click on “Customize Current View…” under “Current View” on the “View” menu:

Next, press the “Automatic Formatting…” button:

Push the “Add” button to create a new formatting rule:

Name it something useful, press the “Font…” button and pick the formatting you want, then press the “Condition…” button and set up a rule, such as:

Voila! You’ll have a cool, new service that reviews webcasts and lets you know which ones you should be watching!

Thanks, Tim, for wading through all those crappy webcasts to let us know what’s worth watching… and, thanks for making it so easy to actually use your reviews, too!

First, go read Scott Hanselman’s description of ALT.NET and why you should care about it.

He describes a new “code” for describing your level of “ALT.NETishness.”

Here’s mine: