Adding performance

Some of you may have found the title to this blog post as amusing as I do.  Throughout my career, I've been called into many a meeting asking that I "add" performance to a complete or nearly-complete product. No matter how many scowls I got, I could never resist joking about just adding the IPerformance interface.  "And, while you are at it, just add the IScalable one too", I would quip. (OK, I know some of you are doing searches for these interfaces -- don't bother). Laugh as hard as I may, I'm embarrassed to say that I am trying to do this very thing now. 

A few weeks ago, I started playing around with a small sample that shows off some of the fun features of IIS 7. As I started coding, I added more features to the sample. Scope creep is a no-no, but this was something I was doing on my own time so I didn't have a problem with it.  However, the sample got so large that I had to actually stop and design a public API to support it.  By the time I was done, my "sample" had a set of providers, a common API, localization support, utilities, and most notably, performance issues.

Last year on my personal blog, I talked about "engineering for usability".  In that post, I declared that the simplest design is sometimes (and probably most often) the best approach.  That said, performance should have been considered very early on, and the sample should have been kept simple.  Performance, as many of you know, is not something you add as an afterthought.  Starting my sample the way I did, I never considered code performance to be an issue. 

Now I'm forced to decide:  do I scale back my sample knowing full well that it doesn't have a security model or provide easy extensibility, or do I redesign the sample with the current feature set and design for performance up front?  I'm leaning toward the latter despite reciting "keep it simple, stupid" in my head over and over again.

2 Comments

  • Software development is performed by humans? IPerformance, IScalable, IFreebie are all estoeric interfaces known only to management! ;-)

  • Using QRT principles, from the basics of project management, where Q=quality, R=resources, T=time.
    Resources are obviously constrained, given that you have described this sample as a 1 resource project.

    Time and quality are variable, with time assumed to fall within some self-defined constraints.

    Given (1) this is a sample, and (2) the project does not demonstrate security as a primary goal, then it would follow to drop security as a feature set to achieve a goal in the desired timeframe.

    KISS ,and YAGNI (You Aren't Going to Need It from extreme programming), are both very applicable to this project.

    Focus, Daniel San, focus! :-) (an 80's film reference)

Comments have been disabled for this content.