Article: The declining importance of performance testing should change your priorities

In this document you’ll learn why the declining importance, and therefore the limited gain, of trying to determine the performance and scalability of systems should reduce the priority you’re placing those activities.

We’ve reached a day when a fast server can handle almost any single load that is thrown at it. For a few thousand dollars, perhaps $5K to pick a round number, you can have a system that will perform adequately to almost any load. Because of this performance testing is becoming a luxury that few can afford.

Of course, there are some organizations that will find that their applications can not be served on a single server or even a small farm of servers. Their tasks will be so large, difficult, or expansive, that no single piece of hardware can solve the need—however, the number of organizations with those needs is dramatically shrinking.


Article: Avoiding Coupling in Your Portal Implementation

Software development has for a long time sought to reduce the amount of coupling between various components of the system. The goal was creating systems where parts could be replaced without requiring massive amounts of rework — or simply replacing the whole system.

Portals, which are necessarily at the heart of an ever-changing array of programs and solutions within the organization are especially vulnerable to coupling. It starts out simple at first: the special notice that one application needs, and before long your portal projects are caught behind the schedule of a dozen other applications — and a dozen different projects are waiting on your portal project to be revised before they can put changes into their products

No matter how careful you are, there will be some coupling to other systems that cannot be avoided. However, taking a stand against allowing your portal to become coupled to other systems can make it easier to continue to update and revise your portal.


Thoughts on Optimisim and Pessimism

Thomas Edison was once asked about his failures in creating the light bulb and his response is often quoted as “We now know a thousand ways not to build a light bulb.”  That’s a dedication to staying positive that few (if any) of us could muster these days.  It’s a passion for creating the light bulb that would not be discouraged.
Through some of the reading I’ve been doing lately, I’ve been consumed with thoughts about how you perceive the world around you will drive how the world around you becomes.  This probably isn’t true in the literal sense (however, I wouldn’t discount it.)  What is true, however, is that we have two types of people: The optimist, always believing that there is more than their really is – but happy in that thought, and the pessimist, always believing that there is less than there really is – and miserable or fearful in that thought.
The classic is to place a glass with water equal its total capacity and ask if it’s half empty or half full.  The optimist is supposed to answer that the glass is half full while the pessimist answers that it is half empty.  A few severe pessimists, and I know some, would tell me that the glass may only be half empty now but due to evaporation, perhaps a crack in the glass, unidentified forces, etc., they’re sure that the glass will eventually become empty.  (It’s about that time that I reach over and drink it to prove their point.  It’s a fun thing to do.)
So there’s nothing new here.  You already have heard these things.  But what you may not instinctively realize is that optimism is its own reward.  Sure, I have to accept disappointment.  I’ve set the bar higher. I’ve decided to expect that things will go well, that life is ultimately good.  In return, I get to delude myself into a happy state.
And, of course, the “storms” will come, as they always do to try to convince me that the world is an ugly place.  And at those moments, I’m frustrated, disappointed, and worse.  However, that happens so rarely, that I get most of my days filled with happiness.
The mother of one of my friends is a pessimist, the kind that believes in evaporation, she recently shared with her daughter – “See, I was right.” It was in reference to some pessimistic “The sky is falling” prediction.  The answer back was the classic answer from an optimist: “So what, if you always predict something bad will happen – eventually you’ll be right about one of them.”  In other words, the optimist doesn’t have to assume that everything will always go right, they can be realistic about bad things happening, and they just believe that it’s a small proportion of every day life.
Fairly recently we were at a zoo and had our son’s wagon stolen.  We were able to recover it in relatively short order, however, its impact on our son’s small mind was fascinating to watch.  It had never occurred to him that someone would steal.  Why would you take something that wasn’t yours?  This plus trying to figure out both mommy and daddy’s reactions was putting his poor little mind into overdrive.  The end result was we got the wagon back.  He still vividly remembers the incident (perhaps too vividly.)  He has changed his behavior.  He still takes his wagon to the zoo; however, we keep a closer eye on it.  He didn’t give up.  He didn’t refuse to enjoy the zoo just because a bad thing happened – he simply is more aware of the possibility of a bad thing happening and tries to plan for it as best he can.
So my parting thought, a quotable, is simply this:
“Failure is only not trying because there is no hope of success.  Persistence guarantees eventual success through hope.”
Be an optimist, what do you have to lose?
Peopleware: Productive Projects and Teams

Book Review-Peopleware: Productive Projects and Teams, 2ed

I have to say that I was a bit embarrassed to tell people I was reading Peopleware: Produtive Projects and Teams.  It wasn’t because the material wasn’t good — it definitely is.  It’s not because I felt squeamish about the title — I didn’t.  However, I did feel like I should have somehow managed to have read it before now.  With the original edition written in 1987 and the 2nd edition written in 1999 — I should have read it before now.  Alas, I hadn’t.

Peopleware is, as the title suggests, about people.  It’s about how people and software development fit together.  It’s not another methodology, it’s not a set of programming tips.  It is, however, some interesting insight on how people work, don’t work, and work together.  It has hints of Dilbert in that it talks about the things that managers can do to effectively eliminate productivity within a group.

I collected a few quotes that I believe highlight the value of the book:

  • “The major problems of our work are not so much technological as sociological in nature” (p4)
  • “The statistics about reading are particularly discouraging.  The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.” (p12) [Ouch]
  • “People under time pressure don’t work better; they just work faster.” (p18)
  • “Speaking of software, that industry has accustomed its clients to accept in-house developed application programs with an average defect density of one to three defects per hundred lines of code.” (p21)
  • “People just don’t work effectively when they’re locked into a no-win situation” (p28)
  • “The manager’s function is not to make people work, but to make it possible for people to work” (p34)
  • “People can keep track of only so many human interactions” (p137) [This is particularly interesting if you account for the maximum practical size of a group of people (see The Tipping Point) and the fact that most Agile methodologies work best with smaller groups.]

The book read, to me, as the background information one needs to understand why agile methodologies work.  It’s sort of like reading a book about the internal combustion engine when you drive a car to work every day.  You don’t have to know how the car runs, but when you break down on the side of the road it comes in really handy.

If you’ve not managed to make it through this classic work and you work with others as a manager or as a team member — you should.


Jupiter Media SharePoint articles

I do a fair amount of writing for Jupiter Media.  They have a large number of sites which cover a complete range of technical topics.  One of the sites, Intranet Journal, has an index page to the SharePoint content that they have.  I reference it all the time to people because it’s a great way to see several people’s thoughts on SharePoint in one spot.  The url is  It’s simple and something I can remember.

From there folks can find my articles and the articles of other folks who’ve written on SharePoint at any of the Jupiter Media sites.

… now I have one less random thought I have to hold in my head.


Presentation: Tips and Tricks For Recovering a Rogue IT Project

Tonight I gave a presentation to the TechPoint IT Professional Peer Group titled “Tips and Tricks for Recovering a Rogue IT Project”  It was a great open discussion with 25 IT professionals about project management and the traps we all fall into.  I’ve attached the presentation so that everyone can get a copy if they would like it.

Ever run into Bidi?

One of the interesting acronyms that I have run into in SharePoint is Bidi.  I never really knew what it was  and frankly I put into the category of “I hope I don’t have to know.”  I mean really, there are so many things you HAVE to know in SharePoint to get anything done, can’t I get by without knowing what BiDi is?

I found out the answer is no, I don’t have to know what Bidi is … until I go to multi-lingual sites.  I stumbled across it in a blog post for IE.

Professional .NET 2.0 Generics

Book Review-Professional .NET 2.0 Generics

I was trying to post a comment today to check out a book — a book that I had read and thought I had blogged about but apparently I blogged about it in a dream.  (Yea, I know sick)

The book is Professional .NET 2.0 Generics while I can certainly tear apart some of the mechanics of the book, overall it’s a thorough coverage of the topic both from a breadth and from a depth perspective.  I remember learning more about how the CLR works and the impact of a compile time vs. run-time type generation than I thought possible.

If you’ve got more than a passing interest in generics you should check it out.  You never know, you may just become the generics expert at your organization.


Getting Jr. Developers to Review Sr. Developers Code

Ben Fulton was at a recent presentation I gave on the Impact of Coding Standards and Code Reviews on Quality while reviewing some of my referrers I came across a link to his blog.  (Yes, I do occasionally go into my referrers, mainly to thank people for the link — thanks Ben.)

The one question that he raised on his blog that I didn’t fully understand during the presentation was “How do you get a Jr. Developer to review a Sr. Developer’s code?”  Here are a few of my thoughts on this…

1) It’s a lot about personality and relationship.  If you make the developer understand that it’s not about experience or position and is just about working together as a team it gets easier.  I find that it starts to become natural after the culture shifts towards people doing reviews as a habit.  Trying to make the Jr review the Sr developers work as the first thing is a bad idea.

2) It doesn’t have to be a formal code review to have value.  I can’t say that the majority of times that I hand code over to a Jr developer that they do a full code review.  However, I do make it clear that it’s their name that’s checking it into source control so they’re responsible for it.  If I make a mistake they will be held to fixing it by their peers.  It’s a part of the team commitment.  So they may not send me back a complete set of comments, however, my hope is that they at least read the code.

3) If you can’t get comments at least get a read.  Code reviews seem to work based on a whole bunch of factors.  Simply reading each other’s code makes everyone better.  It helps you understand what the other members of the team are working on and exposes potential descrepancies between your interpretation or understanding and theirs.  This is a good thing.

At any rate.  Good luck with getting code reviews to work in your organization.

Micro ISV: From Vision to Reality

Book Review-Micro-ISV

When I blogged about Software that Sells: A Practical Guide to Developing and Marketing Your Software Project I commented that there wasn’t much information that was in the book that I didn’t already know.  The guide was really very light on details.  Micro-ISV: From Vision to Reality is a very different story.  I found all kinds of things in the book that were interesting.

I rarely “dog ear” a book these days.  I make it a point to have a pad of paper and pen with me when I’m reading a book.  That’s mostly so I can record my thoughts.  Sometimes I’ll stop reading and start frantically scribbling notes.  Anyway, it’s lead to a lot of books that don’t get “dog eared.”  I even have tape flags that I use to mark what page I’m on — thus no “dog earing.”

However, I haven’t even made it through all of the pages I “dog eared” in Micro-ISV.  There seemed to be a new web site or product that I didn’t know about on every page.  Admittedly Micro-ISV will have a relatively short shelf-life in terms of it’s value because web sites change and companiese go out of business.  However, for now, it’s a great reference for those who are struggling to get a product company going.

The other interesting thing about the book is that it has a great number of interviews in it.  Real people with real problems not unlike your own talking about them.  All in all, a good read.  (I suppose it doesn’t hurt that the author is a former reporter.)