Fundamentals of Performance Testing

Robert Bogue January 21, 2006 No Comments

I’m in the process of writing an article for TechRepublic.com on the declining importance of performance testing. Without getting into the articles primary arguments, I came to a realization that I felt compelled to share.

Most IT professionals have no idea how to approach performance testing.

I mean that both from the sense of they couldn’t do the testing if the needed to and also from the perspective that they don’t truly understand how it works. The article for TechRepublic.com is, as most of my articles are, born out of experience. I’ve noticed that way too many organizations get hung up on performance. They avoid items which have been identified as non-performant but which make the development process much easier and therefore it costs less.

So in the interest of educating folks, here is a high level summary of what you should know about performance testing, the details will be in the article …

Performance Testing – Performance testing is really a set of related evaluations of the system including: responsiveness, throughput, and scalability.
Responsiveness – Responsiveness is how quickly the system can complete an individual transaction. As the throughput of the application goes up responsiveness typically goes down.
Throughput – Throughput is the rate at which transactions can be completed. Typically maximum throughput is the number that organizations are trying to find.
Scalability – Scalability is the amount to which various changes to the environment can impact the maximum throughput and to a lesser extent improve responsiveness. Different changes can result in radically different effects on throughput expecially when the scalability is directly related to a bottleneck.
Bottleneck – A bottleneck is a performance constraint in the system which prevents the throughput from increasing. Typical candidates for bottlenecks are processor performance, available memory, disk performance, and network performance.

I hope this helps.

Article: Choosing Between a User Control or a Web Part for SharePoint

Robert Bogue January 20, 2006 No Comments

I generally recommend that users don’t write Web Parts unless they have to. That confuses a lot of people since most people believe that you have to write Web Parts if you want to do work with SharePoint. This is only partially true.

SharePoint will only display Web Parts on a page. However, there are publicly available shims that allow you to write user controls and have them be displayed as a Web Part. From SharePoint’s point of view, the shim is a Web Part. From the point of view of the user control, the shim is simply a control in .NET that is including the user control.

http://www.intranetjournal.com/articles/200601/ij_01_20_06a.html [Website no longer available]

Book Review-The Tipping Point: How Little Things Can Make a Big Difference

Robert Bogue January 19, 2006 No Comments

If you’ve been reading this blog then you know that I’ve been doing a lot of reading of my own lately, mainly associated with some professional development in the area of reconnecting to basic software development fundamentals that I’m already aware of and some new things as I try to find some new ideas in the various forms of the agile development movement that I can use or try.

The latest book is radically different. It’s one that was casually mentioned to me by a colleague, Jeff Juday, who was recently awarded Microsoft MVP status. He mentioned how he thought the program related to the book he had just read, The Tipping Point.

This piqued my interest initially because I’m always curious about how the market works and Jeff promised the book would have some insight. (He was right.) Having written (or written part of) 16 books, I know how random sales can be from one title to another. In fact, when my friends and colleagues approach me about writing a book and ask me if their idea is a good idea, I usually respond with I have no idea. The market seems to work in mysterious ways.

The Tipping Point is a book about epidemics. Not so much the negative things as we associate with the word epidemics but rather about things that have a radical growth cycle.

At some point in the book, I wanted to share a passage with everyone I knew. Some of my mentors, the pastoral staff at the church I attend, my mother, several of my friends, and some of the folks I know at the MVP program at Microsoft. The truth is that when I finish this blog post many of them will be receiving a link via email to check it out – excluding those I know read my blog regularly and so they’ll see it anyway.

I found the book enthralling as I examined some of the market reactions I had seen. The birth of the Internet (really the adolescence of the Internet), the growth of cellular phones (which the book discusses), and I even thought about it in terms of SharePoint Portal Server. (For the record, I would have written this blog post even without a SharePoint tie-in.)

I remember working with the 2001 version of SharePoint Portal Server. When I’d talk with my peers most of them would be asking me – “Share What?” There weren’t many people that knew what it was. Today, when I talk about SharePoint to people I meet – even outside of the industry – I get a surprisingly high awareness rate. Most don’t know what it does exactly but they know that people think it’s something to watch. (As a sidebar, most people who do SharePoint work don’t know exactly what it does.)

The interesting thing is looking at this pattern – and others – and evaluating why SharePoint is such a pervasive word in the IT industry and in the minds of small business owners. It certainly can’t be attributed to the stellar marketing that Microsoft has done for the product. (Sorry guys.)

Quietly you’ll get some of the marketing folks in the information worker group to admit that there’s a lot of confusion about SharePoint and few places to find good answers. I’ve had clients pay for us to develop documents that they can use to internally explain the solution – because it’s simply too hard to do without clear documents on what it does and doesn’t do.

SharePoint isn’t successful because of a greater number of people running Microsoft Office. SharePoint’s popularity can’t be explained by a renewed interest in IT. It’s an absolute mystery to me as to why it’s become so popular. (Here’s a challenge – tell me via email why you think it is so popular. I’d love to hear your perspective.)

The Tipping Point didn’t explain why SharePoint has become so popular but it did give me the clues to look for to identify what happened. I don’t have the answers but I do at least know some of the questions to ask. In that way, I think it will be invaluable in the way it allows me to see things more clearly.

The analogy that I’ve come up with to explain it is that it’s like someone with imperfect vision – like myself – putting on glasses for the first time. It doesn’t make me see or allow me to see for the first time but it does bring more clarity to what I’ve been seeing all along. The unfortunate thing is that it has also exposed me to how much I still don’t see.

There are some psychological tenants that most people subscribe to – including me. That I know believe are false. I’m questioning how much about the way people behave is about their character and how much is about their circumstances. (In an interesting turn of events, the environment swapping movie Trading Places was on TV last night.)

If you’re the least bit curious about how trends get started and would like to get a little bit better picture of them I highly recommend reading The Tipping Point.

Recognition vs. Recall

Robert Bogue January 15, 2006 No Comments

Where did I put that again?

One of the things that’s been fairly constant in my life over the last few weeks — that rediscovery stuff is hard, particularly when you try to do it too quickly. It’s caused me to recognize that there’s information I’ve seen before but I couldn’t recall it on command, nor can I even remember where I saw it again.

It reminded me of some of the instructional design research I did several years ago while I was doing a lot of development editing for books. I ran across Bloom’s Taxonomy of Educational Objectives, while I can’t say that I agree with every bit of the classification or the revision of the work. However, it’s interesting because it causes you to think about how we teach and learn in a different way than we most folks think about it.

What caused me to think about it was the difference between recognition and recall. These are at the bottom most levels of the taxonomy. The most basic level is recognition. That means that if someone asked you what it was you couldn’t tell them but if they say it to you — you will recognize that you heard it before. Taking from my daily life… My wife asks me to pickup paper plates from the grocery store. I walk into the store and can’t remember what it was that my wife asked me for. (I lacked recall.) However, my friend, who co-manages the store walks up to me and starts offering ideas on what it might be: bread, milk, cheese, etc. When he hits paper plates I immediately recognize that it what I’m there for.

The trick, for me, is to figure out how to get more of the stuff I read and take in into the recall category and less in the recognition category. I could be struggling for higher levels, levels that allow me to do things with the information but for now, I’d be happy to hit recall all the time.

Excuse me while I go look for my car keys…

If you’re interested in learning more about how we educate ourselves and others, it’s an interesting read.

Book Review-Agile & Iterative Development: A Manager’s Guide

Robert Bogue January 11, 2006 No Comments

The latest book to succumb to my ravenous appetite for software development is Agile and Iterative Development: A Manager’s Guide.

More than any of the other books, this book convinced me how astray we’ve all been lead astray by waterfall based development. While most of my consulting career has been spent adapting waterfall to meet client needs and the needs of the consulting organization, it’s interesting to realize that the fundamental approach to development was wrong.

I particularly liked this books coverage of details. It talks about how iterative development got started and how current agile practices are linked to iterative development. It also has great coverage of scrup, xp, up, and evo methodogies — and how they work together well and places where they don’t work together well.

All in all, this is a great guide for people who are open to better understanding what they do well and don’t do well in their software development.

An odd little quirk about not installing VB the first time through

Robert Bogue January 10, 2006 No Comments

One of the things I’m doing right now is evaluating DotNetNuke 4.02 … So I install it in my VPC and It doesn’t show up. I think about it and realize that I didn’t install Visual Basic when I installed Visual Studio 2005. Of course, I couldn’t think of any reason why I’d need it.

Sidebar: I’d love to use WSS V3 for this but the site has to be up much sooner than I’ll be able to get a “go live“ license. I’m investigating several alternatives with an eye to being able to make the change later.

I go back in and install it and then go back to try to find the templates for .NET nuke (starter kits more appropriately). I still can’t see them. I learn about the VSI format (think SharePoint CAB deployment packages using ZIP instead of CAB) and the .vscontent files. Cool stuff… After several reinstallations it is still not showing up.

I take a step back and realize that the only web templates I have showing up are C# web templates. Doh. Something must be wrong with the installation. It thinks that I don’t want to do VB … since DotNetNuke is VB… I can’t see it.

I’m trying a repair now … if that doesn’t work I get to uninstall and reinstall VS.2005 to be able to evaluate DotNetNuke.

[Update: It’s an odd interface quirk… I had to select one of the VS templates to enable the language selection lower in the dialog … I love stuff like this.]

Preparing for SharePoint Advisor Live! Las Vegas April 9th-12th

Robert Bogue January 9, 2006 No Comments

I’m just sitting down to get some work done on my presentations for SharePoint Advisor Live! in Las Vegas April 9th-12th and thought I should share with everyone the three sessions I’ll be doing…

Get your SharePoint Project Started Right : SharePoint projects are often lost in enthusiasm and don’t have the requirements gathering they need to succeed. Learn how to get the requirements you need to have a successful project. Find out about techniques for clarifying terminology and for getting the most out of prototyping. Learn real world tips for recovering from bad requirements. Whether your project has already started and is off track or you’re just getting started and are already concerned, this session will help you be successful. You’ll take home a worksheet that will let you make sure you get all the important requirements for your SharePoint project.
Use SharePoint Portal Server Search to Find All of the Information in your Organization : Locked away in the files on your file servers, in your ERP systems, and in your custom written applications is the collective knowledge of the organization. Microsoft SharePoint Portal Server (SPS) can peer into these repositories to collect all of that knowledge and make it accessible to you. Learn how to enable SPS to search all the information in the organization. Learn the details of how SharePoint search works and how to configure it. Learn how to create advanced search criteria in SPS. If you’re struggling with search, then you need to come here to learn how to get control of it.
SharePoint Backup and Restore : Critical information goes into SharePoint each day. Recovering that information in the event of a “disaster” is essential. Learn how to back up the information so you can recover it. Learn about the out-of-the-box backup solutions as well as the third party options for backing up your SharePoint data. After you have fundamental backup options, you’ll also learn to create a backup strategy that allows you the most recovery options. You can’t afford to loose your data so you can’t afford to miss this session on the ways to recover from a “disaster.” Take home a solid understanding of the backup options and their benefits and weaknesses.

I’m looking forward to seeing everyone there!

Are you really saving money through off-shoring?

Robert Bogue January 9, 2006 No Comments

Let me first start out with two process notes…

1) It’s hard to get an article like this published on the Internet because of the substantial amount of web traffic which is coming from off shore. That’s why this is a blog post.
2) I have the GREATEST respect for many folks who happen to be outside the US. This isn’t an attack on the idea in general — it’s an open conversation (albeit one sided) about some of the ways that outsourcing costs more and no one can see it.

First, as I’m preparing to push for my new commerce web site (softwarewishingwell.com) I’m seriously looking for being as efficient as possible. That means the review of techniques and thinking that I’ve been doing, but it also means looking at how to acquire the construction resources I need. (I’ll be doing most of what represents requirements and design myself — in whatever form it takes.) I’ve found a few different options for getting the construction done — and they look like they’ll be a great way to keep my costs down. However, I’ve also seen first hand how off-shoring can fail to work. Here are a few warning signs that I think many organizations miss…

1) The off-shore resources aren’t following coding standards (or you don’t have coding standards). This just means tons of rework with no hope of any escape.
2) The off-shore team doesn’t receive any training of any kind. You don’t coach them on how to develop software better. You figure that they’re contractors and you shouldn’t waste your time on training people who aren’t on your staff. The fallacy with this idea is that you don’t realize how much cost you’ll incur between the time you identifiy they need the training and the end of YOUR project.
3) You’re noticing a high defect rate. Of course, you’ld have to actually track defect rates and associate them to the code that caused them (which many organizations fail to do). If you did you might notice that a disproportionate number of your defects are coming from off-shore.
4) You’re having to define things in such detail that you feel like you’re spending more time specifying the code than it would take to write it (and you’re not getting what you asked for.) If you can write it faster than it takes you to write the specification… then you might want to just write the code.

Most people ignore the warning signs above because they don’t measure the right things, they’re oblivious, or they simply don’t want to hear it.

Remember that finding a defect late in the process can cost 100 times as much as fixing it quickly. The fewer repeatable defects you’re fixing the more likely you are to find the important defects that might slip through.

A final note, both traditional plan-based development and agile development work better with better developers. Agile is particularly sensitive to having good developers. If you’re not helping your developers become better, you’re shooting yourself in the foot.

Agile Development through Lunch

Robert Bogue January 9, 2006 No Comments

As I’ve mentioned in previous posts, I’ve been doing a ton of personal reengineering, trying to get caught up on my personal and leadership practices for software development practices.

One of the things that struck me through my reading is that there are Agile techniques that I’ve been using for a while. One of those is trying to gather the team for lunch. Why? Well, we all have to eat… and it gives us a chance to have more time to interact. We rarely spend the whole lunch talking about the project, we talk about jumping out of planes, how crazy I think it is to jump out of a WORKING plane, gadgets, etc. However, we often slip into project conversations for a few minutes to ask a random question, or clarify something. It’s part of the randomness of the human condition.

I never gave it much thought, it was just something I did to make sure that the team was staying connected. It turns out that one of the foundations for agile development is improved, frequent communication. Alistair Cockburn recommends being close to each other in the office. While that wasn’t always possible it was generally possible to gather the team up to go to lunch together.

… hmmm, Come to think about it I frequently used IM to “gather the troops”… I wonder if that’s a supporting technology for agile development ;)

Book Review-Balancing Agility and Discipline: A Guide for the Perplexed

Robert Bogue January 6, 2006 No Comments

I mentioned briefly in my last post that I was reading Balancing Agility and Discipline: A Guide for the Perplexed. I managed to navigate my way through the end of the book and wanted to record my initial thoughts about the book and about my growing perspective on Agile software development in general.

On the book…

The fundamental question that the book answers is how do you take the best of Agile development and integrate it into your current software development methodologies. It neatly disguises this question under the auspicies of exploring the places where each method “belongs.” — their home ground. It does what appears to be a very thorough job of reviewing the strengths and weaknesses of both traditional (plan-based) development and agile development.

My current thinking about Agile development (and software development in general) is this…

1) Agile software development makes the same statement that traditional development does — better programmers make better projects. I was struck with how much emphasis good software development –whether traditional or agile — places on good developers. (It would be more accurate to say good participants.)

2) Agile software development is like Voodoo — at least in the movie Dogma’s definition “Do you know about voodoo? No constitution of faith, more an arrangement of superstitions.” In other words, it’s a collection of techniques — some shared between different agile variants, some shared with more traditional plan-based development, and some shared with project management practices. The percentage of people following a specific technique is very low.

3) Agile is akin to “Management by Wondering Around” one of the practices made popular by In Search of Excellence. It focuses on people actually talking to each other. Given the number of large scale projects I’ve worked on where that doesn’t happen — I’m all for people talking to each other. ;) In a more serious way, the focus is on individual and personalized conversations with people. Answering their specific needs and coaching them into effective behaviors — one by one.

4) The arguments that are being used by both sides of the isle represent a fundamental lack of understanding. It reminded me of a recent set of posts on the Dilbert Blog about Intelligent Design vs. Evolution. [Warning: The preceding link may consume a huge amount of time as you try to figure out which of the arguments are the dumbest.]

5) We’re all missing the point … We start good development by getting good people involved. We get good people involved by DEVELOPING / CREATING / BUILDING good people. If we’re not all willing to go out of our way to help other people become other developers — every day whether it makes sense to the particular project or not — then we may be doomed to struggle with poor software developers forever.

The good news is, however, I’m more agile than I thought.

Public Speaking

Recent Posts

Public Speaking