Posts
1147
Comments
891
Trackbacks
1
August 2009 Blog Posts
Institutional Knowledge

Anne Epstein has a great post about what she calls “Institutional Knowledge.” 

In her post, she focuses on the current economic situation, and the fallout from letting go of staff that has this institutional knowledge, but I think what she says can be more generally applied and understood.

You can read the original to see all the details, but she talks about an old Dodge Caravan she had, and the specific ‘quirky’ things she needed to do to get it to function properly in various situations (I can relate…I had an old Pontiac GrandSomethingOrOther that was similar…I've forgotten the details of everything but I remember in particular that the driver side window had some internal piece that was broken so that if you needed the window to stay up, you had to crank the manual thingy all the way to keep it from dropping into the door frame, and if you needed to roll down for a toll booth, you had to loosen it just a bit to get it to come down, but only a little, as you had to crank it back tight to keep it from dropping into the door frame…then you had to loosen it a bit and push up the window with your hand to close and then crank it back tight….or something like that…the fact that I don’t remember all the details proves the point, but I digress). 

Most anyone who has dealt with applications that have existed for any period of time knows how this applies.  End-users, in particular, learn to work around the bugs of an application by applying ‘tricks’ that allow them to get around the bugs and do what they need to do.  I remember an application that required you to click a button to perform an action, but for whatever reason that I no longer remember, you had to click the button twice.  The first time, it would fail with some cryptic error message, but the second time it would work.

In other cases, it involves the usage of particular terminology.  I worked on an application that had a fairly robust audit history system, where you could track who did what and when, but there was a background process that needed to run in order for the history to reflect accurately.  I was asked to look into a defect and see if it was because the “AuditDTS” didn’t run.  As a SQL guy, I knew that meant I should look at the DTS packages and see what was up, except that the background process had been changed to use something else (SQL Agent, I think) and it took me a while to figure this out. 

The aspect that is most prevalent for Institutional Knowledge is that it isn’t documented anywhere.  It resides in the minds of people.  And sometimes, those people no longer work for the organization.

Ideally, software is designed so that it is resilient to this, but the ideal is rarely met perfectly.  Learning the institutional knowledge surrounding an application is often just about as important as understanding the code itself.

posted @ Saturday, August 29, 2009 7:26 PM | Feedback (0)
Aimee Mann – 31 Today

The song has been out for a while, but only found it recently.  The video is…quirky.  But what do you expect from a video produced by Bobcat Goldthwait….what the hell, he produces videos?

Anyway, besides just liking the song, it uses a ‘trick’ that I used to use a long, long, long, long, long time ago when I wrote songs…a ‘perky’ upbeat song that has basically depressing lyrics.  Obviously, I didn’t invent the trick, but for whatever twisted reason, it appeals to me.

I thought my life would be different somehow
I thought my life would be better by now
But it's not, and I don't know where to turn

Enjoy.

posted @ Friday, August 28, 2009 7:38 PM | Feedback (0)
Unit Testing Basics: Make sure the test can fail

Though I should know better by now, I still find myself on occasion (just on occasion, really) making a ‘rookie’ mistake.

You create a spec and code it so that it will pass.  All is good.  Then in some later scenario that the spec should have covered, you find yourself getting a failure.  Consternation, angst…..after 20 minutes (if you are lucky), you discover…the spec was written such that it never could have failed.

When I first was trying to learn unit testing basics, I would get stuck on the advice, “Make sure your tests fail, then make them pass.”  Well, that was easy enough, punch in an Assert.IsTrue(1 == 2).  Obviously, that wasn’t the point.  You needed to set up your tests so that you were setting up expectations and assertions that were relevant to what was being tested.  Make *that* fail, then make it pass.

At least for me, it is still too easy to get in the flow and figure I know what a legitimate failure is, without thinking about it enough.  Doh!

So, make sure your tests fail for a legitimate reason.  That’s the ‘red’ part of red-green-refactor.

posted @ Friday, August 28, 2009 7:25 PM | Feedback (0)
TypicalProgrammer on Why Programmers don’t like Relational Databases

This is a very good read:

http://typicalprogrammer.com/?p=14

I especially like the following:

Because most of what programmers do has no theoretical basis or system of proof, programmers back away from anything that looks like hard math. Failure to understand and appreciate relational theory has launched countless bad databases (and thousands of witless articles condemning SQL). The idea that there is a right way to design a normalized database–and that the wrong ways are provably wrong–is alien to most programmers. Database management doesn’t come down to a matter of opinion like OOP class hierarchies or coding style.

At times there are calls to get rid of the ‘traditional’ RDBMSs and replace them with…object oriented databases, MapReduce, etc.  Almost all of these calls are misguided. 

When either Oracle and/or Microsoft releases an object oriented database, then you will know when you can ignore them (for the most part, there are always special cases).  Until then, you need to know how to deal with a database.

Good stuff.

posted @ Tuesday, August 25, 2009 10:02 PM | Feedback (0)
Till Next Time

Those in the know, know that “Till Next Time” is the tagline of Derik Whittaker.

I don’t remember which of us (where ‘us’ refers to Derik, Sergio, and myself) made the post (and I’m too lazy to look it up), but one of us made the suggestion on the old alt.net Yahoo mailing list that people in the Chicago-land area should get together and think about setting up an alt.net group.  We met at some bar up north of Chicago (I’m thinking Fall 2007).  In any event, the meeting went off well enough that Chicago alt.net was born.

Sergio and Derik have basically headed the group ever since.

Anyway, after talking about it for a long time, Derik is finally moving to North Carolina.

Those that know Derik already know all of this, but Derik is one of the coolest guys I’ve ever met.  Besides the fact that we share some common interests about development stuff, he’s intelligent, funny, and, well, there’s no other way to say it, a nice guy.  He’s opinionated (and as people know, I’ve ragged him at times when our opinions didn’t exactly match, but whatever, that’s how I roll), but he knows his stuff and knows how to present it.

Besides the blog that he writes, he’s the creator of the Dimecasts site.  This is a site that I wish had existed 4 or 5 years ago when, as a .NET developer, I started to learn (slowly, very very slowly) about better ways of programming.  The site has (at the time of this writing) almost 140 episodes ranging across a wide variety of topics, and even an experienced developer should be able to find something to learn about there.

He’s not dying, of course, he’s just moving, but I’ll miss getting to interact with him at the meetings.  And I think maybe Sergio might need more help.

Derik does a lot of presentations and conferences and whatnot, so if you have the chance to meet him, take the opportunity.  It will be worth it, he’s an awesome dude.

Till next time, Derik.

posted @ Tuesday, August 25, 2009 8:01 PM | Feedback (2)
Microsoft Office: A potentially telling indicator of the sophistication level of your organization

This isn’t always true, of course, but in my experience, you can get an indication of what to expect in terms of sophistication by knowing what version of Microsoft Office is being used by an organization.

This is a good (and admittedly bizarre) question to ask in an interview when they ask you “do you have any questions for us?” 

If they tell you anything before Office 2007, then there is a pretty decent chance that when you get to look at the code base as a developer/architect, there is gonna be some pain experienced.

If they answer “We don’t use Microsoft Office, we use….”  and it is StarOffice, OpenOffice or Google Docs, then all bets are off.  It could be the best job you ever had or the worst.

posted @ Tuesday, August 25, 2009 7:17 PM | Feedback (3)
Abject-Oriented Programming

This if from a few years ago, but it is a very good read:

http://typicalprogrammer.com/?p=8

I’m not sure which is funnier.  The post itself or some of the comments from readers who didn’t quite get it.

I really enjoyed the Virtual Classes and Functions section.

posted @ Monday, August 24, 2009 6:50 PM | Feedback (0)
Mobile Browsing

For various reasons, I’ve spent significantly more time recently browsing the web from my phone (Samsung Epix). 

I’ve always thought that browsing from the web was lame.  I still do, but since I do it more, I’ve noticed certain things that are more annoying than others, and certain things that are more enjoyable than others.

For years now, I generally only watch TV for HD sporting events and the Food Network.  For news and other things, I use this internet web thing.

Being able to read the full article: so one major difference I’ve noticed is that some sites will let you see an entire article at once, while others make you click on something to do so.  MSNBC lets me see the full article by default.  CNN pages articles.  CNN will let you see the entire article but only if you page to the bottom of the defaulted paged article and click on the ‘Full Article’ link.  This is very annoying.  ESPN and CNNSI both page articles, but at least CNNSI puts the ‘Full Article’ link, when available, at the top of the page.

Automatic reformatting of pages for mobile devices: Google Reader does this very well.  When it can, which is most of the time, it will take the content of an RSS item and automatically reformat it so that it fits a mobile device without scroll bars.  This is incredibly useful.

Many sites still don’t optimize for mobile devices: there’s nothing more ‘fun’ than having to try to read a web page from a site where it presents the normal web browser content without optimization.  This means you have to scroll to the right to see the content you care about.  Which is really annoying.

Now that I’ve had to experience it on a more regular basis, I know that it is important to optimize web content for mobile devices when and if possible.

posted @ Friday, August 21, 2009 7:16 PM | Feedback (0)
Outlook 2010 Smile: Previewing Office Attachments

One nice new feature in Outlook 2010 is that if you get, e.g., a Word attachment in an email message, when you click on it (just click, not double-click), it will open that attachment within Outlook itself.  That is, it doesn’t launch an external instance of Word, it just displays it in a ‘previewer’.  It also works with Excel (I don’t know what other types of attachments it works with, those are the only ones I’ve tested).

Does this cure cancer?  No, of course not.  But it is a nice feature.

posted @ Friday, August 21, 2009 7:00 PM | Feedback (0)
Windows 7 Themes – What does that sound mean?

So, now that I am running Windows 7 RTM, I have played around with the various themes you can use.

I mainly do this so that I can get pretty pictures on my desktop (I’m using the ‘US’ theme at the moment), but along with the pretty pictures, you get pretty sounds.  Which is fine.

Except that I don’t yet know what all of the sounds mean or what triggers them.  Which means that at odd, irregular times, I get some pretty sound to play.  Which is fine, but I still haven’t the slightest idea what many of them are actually indicating.

posted @ Friday, August 21, 2009 6:48 PM | Feedback (0)
NMock2 isn’t dead, it’s just moved

I’m working on a project where I use NMock2 as my mocking framework.

Since I had never used it, I did the usual and googled it.  For whatever reason, it directed me to:

http://www.nmock.org/

Which of course made me discouraged.  Clearly not a live project.  Later on, I googled “nmock2 dead” and low and behold, it directed me to:

http://sourceforge.net/projects/nmock2/

Much better.  From first glance, still not as ‘vibrant’ as Rhino Mocks or MoQ from a community perspective, but definitely active.

posted @ Friday, August 21, 2009 6:40 PM | Feedback (0)
Maybe we should talk about Sustainability instead

So, the topic of ‘Maintainability’ has come up again in various forums, sparked by Frans Bouma with his blog post and other comments (Update: though I should add that Maintainability wasn’t the direct topic of Frans’ post, as he correctly points out.  However, a lot of the commentary that followed from it centered around this topic, and what they saw as the implications of his post, and that is what I did as well).  Jeremy ‘counting till 10 till jdn calls me names on the net again’ Miller has this, Ayende has this, Patrick Smacchia has this, Jimmy Bogard has this (okay, maybe this one is slightly off-topic), and I’m sure there are a couple dozen/hundred more that could be listed.

I’ve said various things about the topic here, here, here, as well as (sort of) here and here.  Gosh.  That’s a lot of ‘here’ here.

A ton of what I’ve read over the past few years about maintainability has focused on developer activities.  And what I’ve argued (or at least stated) previously is that maintainability as a concept only really makes sense when tied to the the context of those who are maintaining it.  For the sake of argument, let’s assume that it is a given that, in some abstract sense, writing a .NET web application using ASP.NET MVC is better than using ASP.NET web forms, if only because MVC better separates concerns by default.  It’s easy to caricature things, and since it’s my blog, let’s do that: cramming everything into the code behind of a web form, in some abstract sense, is clearly worse than separating out concerns into separate models, views and controllers.  If you have a direct data access call in every web form, then if you need to change the implementation of those calls, you have to (potentially) re-write those calls in multiple places, whereas you have to re-write them in fewer places otherwise.  This is a given.

However, if you have a web application using web forms, you have a much larger pool of candidate developers who are familiar with that way of doing things than with MVC.  I’m leaving aside the fact that you can use the MVP pattern with web forms, and also leaving aside the fact that you can teach people, and, with some exceptions, you can teach people to use MVC even if they are familiar with web forms.

The point is, when talking about the maintainability of an application, at a developer level, you should take into account who is writing the code now, and who will be maintaining the code in the future.

Many people will argue (or at least state) that any application that follows, e.g. SOLID principles, is, in principle, more maintainable than one that doesn’t.  I agree with this, as long as I’m allowed to point out the ‘in principle’ part.  If you are in charge of maintaining an application of any significant size, you have to take into account whom you think will be doing the maintaining.

Regardless of all that, what I think is really more important when it comes to deciding things (is that vague enough?  Yes, I think it is) is to talk about the sustainability of an application.

Sustainability involves the entire life-cycle and process chain, which includes how the organization that has/runs the application defines gathering requirements, validating functionality, develops code, deploys the application, and manages the application in production.  This is *always* determined within a context, the context of the organization as a whole.

One of the fun things about being a developer who reads a lot of ‘alt.net’ type stuff is to read about all of the ‘newer’ (not ‘new’ in the sense of invented, usually, but ‘new’ in the sense of learned from other developer communities, for instance) ways of writing code, code that is easier to change and manipulate down the road.  But, in my experience, the ‘developer’ side of an application is often a much smaller piece of the puzzle than other factors.

Suppose for the sake of argument that you need to implement a new piece of functionality in an existing application that was built with only the slightest understanding of SOLID principles.  Suppose this new piece of functionality takes a month to implement in development.  For the sake of argument, suppose that you know that if the application had been built with even a slight understanding of SOLID principles, you could implement it in a week within development.  I think that some/many/most people would say that the latter case was more maintainable, in some abstract sense.

But suppose that, regardless of the amount of actual development time involved, it still takes a month to manage the requirements, and then a month to QA the functionality, and then a month to deploy the functionality.  The development part of the equation starts to lose importance.  If it also requires a significant retraining of production support staff to learn new ways of figuring out production problems, it really starts to lose importance.

Learning how to build a sustainable application involves a hell of a lot more than just having the development team employing the latest tricks and techniques that they read off the latest post from their favorite blog.  Though this might seem controversial, having an application that has less separation of concerns but is easier for the production support staff to understand, so that that staff can potentially fix production problems without having to call the developers who developed it, is in many instances more sustainable.  And, as someone who managed 2nd and 3rd shift employees, I want to make it clear that this isn’t a matter of insulting production support staff.  But, the fact of the matter is that, generically speaking, brilliant developers don’t want to work 2nd and 3rd shifts.

None of this should be taken as a suggestion that you should lobotomize your development team.  Far from it.  But, it should be taken as a suggestion that when it comes to developing software, what makes it more maintainable for the developers might not be the most important thing. 

If it takes 12-18 months for a business requirement to make it into the developer pipeline (which I’ve experienced, theoretically), that it takes a month versus a week for the developer to get their job done is rather irrelevant.  It would be much more important in that context to make it take even 2 months for the business requirement to make it into the developer pipeline than to spend all that much time worrying about if a developer has to cut and paste some code.

Sustainable software development requires focusing on the entire process, not just on what developers do.  Even though what developers do is usually the fun stuff.

posted @ Wednesday, August 19, 2009 8:15 PM | Feedback (0)
Honestly, I still don’t quite understand what “Oslo” is

But, the team responsible for it is merging with the Data Programmability team.

Time will tell what this means.  And whether I will get it.

posted @ Tuesday, August 18, 2009 6:32 PM | Feedback (0)
Developer Cats and Dogs Living Together, Mass Hysteria – A recurring series

So, Rob Conery is leaving Microsoft, and someone else has to keep developing the MVC-Storefront/Kona app at Microsoft, and that person is Bertrand Le Roy.

Anyway, he/they decided that they need to replace the data layer and so they chose…….NHibernate.  That’s right, not Entity Framework, NHibernate. 

It should be interesting to see where this goes.

posted @ Monday, August 17, 2009 7:25 PM | Feedback (0)
I can relate

Spoken by boss in meeting:

I’m not angry.  This is just how I talk.

posted @ Monday, August 17, 2009 5:33 PM | Feedback (0)
How not to advance software development practices

Jimmy Bogard, creator (I think, he’s listed as a Coordinator, but I think his role is much more than that) of AutoMapper, has a post up about Continuous Learning, where he states:

One of the more tiring arguments against ideas like Agile or Lean is the line of “gee, it used to be RUP, now Agile, now Lean.  Make up your mind!  I’ll come back in 2 years when it’s something else shiny you’ve latched onto.”  But that’s not an argument against ideas, it’s just an argument against change.

and:

So we have two options – cling to what we know and understand for as long as there is a market for that expertise, or, continuously learn and grow.

Now, I (sort of) get where he is coming from.  If you’ve ever been in an environment where you try to advance current practices, and get a lot of riff-raff complaining about it, it can be incredibly frustrating.  “We don’t have time to do unit testing.”  Right, sure you don’t.  You have more than enough time sitting in debug mode trying to figure out why something doesn’t work, but taking preventative measures to allow you to avoid having to get to debug mode, no, that’s too time consuming.  Certainly.

However, the attitude he expresses is something I might call ‘The curse of the software craftsman.’ 

I’m not a grizzled veteran (okay, maybe I am) but I’m not a newbie.  I’ve been in professional IT since 1996 and done software development since 1998 or 2000 (depending on how you count it).  I’ve dealt with countless people who have been convinced of the ‘inherent greatness’ of all sorts of things, and what is notable is that the ‘ferventness’ of them seems to be equal, regardless of the actual greatness of what they’ve been in peddling.

Agile seems to breed people infected with the curse.  It isn’t the worst breeding ground (Linux beats it hands down), but it is pretty bad.  People who have learned Agile techniques seem to think that if you don’t immediately embrace Agile techniques, you are either against change or a Luddite or just stupid or something, and this is incredibly short-sighted.  It’s also just bad marketing.

I was lucky enough to be able to work with a guy who did Agile, and was otherwise incredibly intelligent, a much better developer than I am, who just did it.  I was able to pair program with him on one occasion, but was also able to observe him do TDD.  I learned to know when he had time to talk with me by observing if his NUnit test suite had a bunch of red tests (he already ‘broke the rules’ by writing multiple failing tests instead of doing them one at a time…all the more reason why I respected him) or if they were all green.  I wanted to learn what he was doing and why he was doing it, not because he was proclaiming his greatness, but because I could see it was helping him.

Setting up a false dichotomy of “either you agree with what I am doing or you are resistant to change” just doesn’t help.  This is especially true of Agile/Lean.  If you aren’t in an environment of the correct sort, you end up with fake Scrum or false Agile, where your daily standup involves everyone sitting down, etc.  You are better off not trying to do it at all (though maybe a Kanban board would help regardless).

Jimmy’s clearly a better developer than I am. I’ve never worked with him, but I can state that with confidence.  He’s probably also someone who, in a better moment, can be a positive advocate for change.

But his message of “you’re either continuously learning or you’re a moron” doesn’t really work. 

posted @ Sunday, August 16, 2009 11:34 PM | Feedback (1)
Insulting a PGA Major Winner

I know I’ve posted this before, but I’m too lazy to find the URL, so I’ll recap again.

Rich Beem won the PGA Championship in 2002, beating Tiger Woods by one stroke. 

The following year, the PGA Championship happened to be played in Rochester, NY, and as it happened, I was visiting a friend the week before the tournament was played.

Sitting in the hotel bar on a weekend night (maybe Saturday night), an NFL preseason game was on, I think it was the Giants vs. Bills.  I was killing time before going out to dinner, and somehow gambling came up, and I made the comment (paraphrasing): “If you are betting on the outcome of this game, you’ve got a serious gambling problem.  Seriously.”  I then left.

At the end of the night, I came back to the bar for a nightcap, and was talking to the bartender.  Turns out that Beem had been sitting right next to me when I had made my previous comment.  And had a bet on the game.

I rock.

posted @ Friday, August 14, 2009 8:36 PM | Feedback (0)
Bad Football Announcing 2009-2010: Preseason Start

While the baseball game I was watching was in commercial, I flipped over to the Cardinals-Steelers game on ESPN with the normal Monday Night crew (whoever that is this year…Tirico, Jaws, and Gruden, I think).  Anyway, 1st drive of the 1st quarter, and they are going over the Steelers lineup when Jaws says something like this (paraphrasing):

Well, the Steelers were only 23rd in rushing last year, so the offensive line is going to have to step it up.  That’s just not getting the job done.”

Uh, Jaws?  The Steelers are the defending Super Bowl Champions. 

It’s going to be a great season.  I can already hear Kirk and Brent warming up.

posted @ Thursday, August 13, 2009 7:18 PM | Feedback (0)
Employing the Domain Model Pattern

Udi Dahan has yet another good read in MSDN Magazine, where he talks about the domain model pattern.  I particularly like a couple of things about it.  One is a comment about what the domain model is not:

If you had come to me a few years ago and asked me if I ever used the domain model pattern, I would have responded with an absolute "yes." I was sure of my understanding of the pattern. I had supporting technologies that made it work.

But, I would have been completely wrong.

….the No. 1 most common fallacy about employing domain models. I myself was guilty of making this false assumption for a number of years and see now where it led me astray.

Fallacy: Any persistent object model is a domain model

First of all, a persistent object model does not inherently encapsulate all the behaviors of the business that are likely to change. Second, a persistent object model may include functionality that is not likely to change.

This is a confusion that I’ve seen come up in a number of different ways.  At one of our Chicago Alt.NET meetings, we did a fishbowl session that revolved around DDD and whether it was worth it
(or something like that), and a number of people seemed to make the mistake of thinking that if you started off with POCO classes and/or left database design considerations off till the end, then you were automatically doing DDD, which isn’t the case (this isn’t to suggest, of course, that starting off with POCO classes, etc. is therefore bad).

Udi highlights a part of the domain model pattern that doesn’t get a lot of attention.  It isn’t just that a domain model has incorporates both behavior and data, it is also that it incorporates behavior that is subject to a lot of change.

Now, one can obviously argue what constitutes ‘a lot’ of change versus a little, and we can quickly get to ‘how many angels can dance on the head of a pin’ territory, but I think it is important to highlight that doing domain driven design is really much more complicated than it is sometimes described to be.

The other thing I really like about the articles is this diagram:

fig03.gif

The right-side of the diagram shows what might be shown to the user, which does not require you to go through the domain model.  How the data gets to the screen is open to a number of possibilities (I would prefer DTOs), but the general idea is that you don’t need to try to create a domain model that encompasses all aspects of your architecture.  Instead, you can focus on the left-side of the diagram, where actions taken by the user flow down through the domain model (typically, this might be done through commands/events that take the form of messages).

In any event, it’s a good read.  Check it out.

posted @ Sunday, August 02, 2009 8:54 PM | Feedback (1)
No-Man – Wherever There is Light (Live)

From one of the many bands of Stephen Wilson, a live performance.

No-Man - Wherever There Is Light (from Mixtaped DVD) from Kscope on Vimeo.

posted @ Saturday, August 01, 2009 5:29 PM | Feedback (0)