Photo Courtesy of: rosendahl

My first initial answer is … it depends. (Isn’t that the case for everything?) :)

Today I had conversation with a colleague and we were discussing how application developers don’t plan ahead.

This eventually brought up the question/topic:

“Is premature optimization pure evil?”

My colleague stated that all optimization should be done up front, while I on the other hand, disagree. In my opinion all development should be done first and then lets figure out where we might have some problems, with some exceptions (which we both agreed upon).

So, what did we agree upon?

Lets look at a classic example:

Developer Joe and his team were asked to create an order management system that could handle up to 10,000 orders a day. This doesn’t sound like that big of an issue, and Joe and his team also agreed. It shouldn’t be a big issue. A fast database, a fast web server, and a few third party controls to interact with. No problem! Heck, this is pretty straightforward they thought. In reality, the requirements were very straight forward, no hidden features, no scope creep, nothing like that. Heck, it was a dream project come true. With that said - development ensued, and two months later Joe’s team delivered the product and everyone was excited to see the product run from end to end. (By the way, this was not done TDD or with any Agile Methods – which IMO would have caught any of our upcoming issues, if the tests were written correctly. But then again “If ‘if’ was a fifth then we’d all be drunk”).

Joe’s team fired up the application for a demo and ran some orders through it and it worked great. They even ran 10 orders through the system in one minute (~14,400 Orders a day). They had gone above and beyond the call of duty (original requirement being 10,000 orders a day)! They were due for a raise! Life couldn't be better! The system was released and the company started to use it. Orders were flowing through the system without failure and the business was happy.

Until the company decided to sell an exclusive hot item two weeks later …

Then SHTF… All of a sudden, customers were experiencing time outs,  orders were being duplicated, and the customer service line was being rung off the hook. Essentially, all hell broke loose. After looking into the system, the developers noticed that the system had only accepted 6,000 orders. What gives? This system should handle 14,400 according to their tests. *everyone is scratching their head at this point*

Scalability is Relative

Scalability in this case, is relative. While looking at the stats, Joe’s team realized that those 6000 orders came in in about 1.5 hours. This was the first 1.5 hours that this product was available. At the end of the day the company eventually sold under 10,000 units, so why did this issue happen?

Lets take a look at some stats:

	Orders Per Minute	Time Between Orders (seconds)
Original Spec (10,000 Per day)	~7	8.64
Current State (6000 in 90 Minutes)	~67	0.9

Orders Per Minute Equation: Orders / Minutes          Minutes: (HoursInDay * MinutesInHour)

Orders Per Second Equation: Seconds / Orders       Seconds: (HoursInDay * MinutesInHour * SecondsInMinute)

 

Do we see the problem here?

Again, scalability is relative. In this case, analysis and optimization was not done ahead of the time to anticipate the flood of orders at a peak period. The spec was straight forward:  The system is to be designed to handle an order rate of 10,000 orders a day. The system was designed exactly to the spec, and in this case, the system was designed incorrectly.

Now, I have a confession… 6 years ago, I was Joe. Yes, I made this very mistake. I was a hero for a couple of weeks, then SHTF. :) Live and learn. Live and learn.

When We Agreed

My colleague and I both agreed that in certain instances premature optimization should be done, such as this case. The developers should optimize the order process to handle issues at peak times. Perhaps implementing a order service, based on MQ, or implementing a service bus for this type of high-availability process would be the best. In this case, we agree. All of this analysis and optimization should be done up front because this type of thing WILL be a problem at any peak utilization times. We both agree that neglecting to analyze the problem domain can and will lead to performance problems down the road. Plain and simple.

When We Disagreed

My colleague and I still disagree on the statement of “all code should be optimized up front”. In my opinion this is a BDUF approach that I tend to shy away from. I don’t necessary mean that no design should happen up front, but I do think it should be limited. In an agile environment things tend to change, and we need to be able to adapt quickly. Wasting months in front of a whiteboard, with of reams of documentation, and endless meetings only slows the process down if something has to change down the road. Re-updating project baselines, and adjusting documentation and so forth is a huge hassle. I would like to state that there is a place for this type of development though. Some companies do require BDUF approaches because of huge regulatory compliance issues, so sometimes there is not much you can do about it. However process driven approaches such as ITIL and Agile can work together if done properly. With that said, I tend to shy away from BDUF approaches because of a simple example that is also exemplified by Jeff Atwood in a previous post of his (and I agree with him and the many other experts in the field). Jeff adds a third rule to M.A. Jacksons Optimization Rules that I like agree with the most:

And I would add a third: don't optimize work that doesn't have to be done.  - Jeff Atwood

This can be demonstrated as a sort routine. Lets say you have a menu that will be populated via user selections and the maximum number of values you can have in the menu is 100. You can either implement IComparable and utilize the List<T>.Sort() method to sort the class (which utilizes the Quicksort Algorithm) which would be SUPER easy but may not be the “Fastest” method of sorting, or you could write an extension method to create your own sort routine to sort the 100 items. At this point we’re splitting hairs. A millisecond, or even 10 milliseconds, wont matter at this point in UI response. We’re only sorting a menu that will never grow beyond 100 items. At this point, pre-mature optimization is evil. There is NO need to rewrite something that that does the job well enough. Can we do it better? Yes! Is there a need to? NO. We wont get any value out of it. The time spend on development is wasted compared to the benefit to the application.

On the other hand, if the menu had no upper bound limit, then we would want to implement the best sort routine we could because some routines are exponentially faster than others. In this case we would want to optimize early because the possibility of a bottleneck can and might occur in certain situations.

It all boils down to: “It Depends”

At the end of the day, the true answer to “Is Premature optimization evil?” is “It Depends”.

It depends on the problem. It depends on the architecture and design. It depends on analysis of the domain. It depends on the factors which “could” come into play.

Finally, what it really boils down to is: It depends on MONEY. We can optimize all day and gobs of the companies money in development/optimization costs. This is why deep analysis into the problems need to take place. As architects we need to define the business process that could impact our architecture design and implementation and development of code. At some point we need the business to interject into this analysis and optimization party to say “Listen, I’m willing to deal with X, but I’m not willing to deal with Y”. At that point, our jobs as Architects is to define how much X costs compared to how much Y costs. Only then will the business truly know what should be done juxtaposed with what should not be done.

To sum it up in my own personal opinion, premature optimization can be evil. We, as architects and developers need to think about the problem at hand before we write a line of code. As I stated above, there is no need for a full 90 page document on the process, but at least whiteboard with your colleagues. Are you a solo developer and need someone to bounce ideas off of? Join your local user group, join some groups online, visit the MSDN architecture forum and ask questions.

So, are you going? If so, you better sign up quick! Space is going fast!

What is an alt.net open space?

First lets define what an open space actually is…

How Open Spaces Works

Whoever shows up is the right group. Whatever happens is the only thing that could have. Whenever it starts is the right time. When it's over, it's over.

An Open Space conference's agenda is decided upon by the conference participants during the opening of the event.

You can identify an issue relating to the theme of the conference for which you have a genuine passion and for which you will take real responsibility.

Think of powerful ideas that really grab you to the point that you will take personal responsibility to make sure that something gets done at the conference.

You may lead sessions, you may participate as an attendee, you may take responsibility for capturing proceedings, or you may just hang out in the halls and talk with interesting people.

Be prepared to be surprised.

source: altnetconfcanada.com

What Topics Will Be Discussed?

* TDD
* BDD
* DDD
* Agile
* Lean
* Practices
* Technologies
* and more...

Check out the open space details here.

Better late than never…. :)

Our team coordinator, Bil Simser, announced this same thing on his blog a couple of weeks ago. 

Tree Surgeon is a .NET Development Tree Generator.

Basically, we added …

• Support for Visual Studio 2003, 2005, and 2008
• Ability to choose unit testing framework NUnit and MbUnit
• Updated NAnt scripts for .NET Framework 1.1, 2.0, 3.5

Download the release here

 

Note: A full solution is supplied at the bottom of this post if you would like to download it and run it.

A couple of days ago Matt wrote about the new Unity Application Block. The Unity MSDN article describes Unity as:

The Unity Application Block (Unity) is a lightweight, extensible dependency injection container. It facilitates building loosely coupled applications and provides developers with the following advantages:

• Simplified object creation, especially for hierarchical object structures and dependencies
• Abstraction of requirements; this allows developers to specify dependencies at run time or in configuration and simplify management of crosscutting concerns
• Increased flexibility by deferring component configuration to the container
• Service location capability; this allows clients to store or cache the container

Designing a software system architecture with loosely coupled components makes life easier in the long run. A few of the benefits of loose coupling are : maximizing testability, modularizing components, and increase the maintainability of the code.

This is a simple introduction into Unity that exemplifies the simplicity of the container setup. I will cover two options for type registration:

1. Manual Method based type Registration
2. Configuration file (XML Based) type Registration

 

The Example Application

The application that is included at the bottom of this post is visualized via the class diagram below. This simple application utilizes very simple implementations of the repository, mapper, domain model, data transfer object (DTO) and service layer patterns for example purposes.

The application follows a very simple flow as shown below:

 

The console application calls into the Service layer which calls into the repository to get the data which calls into the DB. A domain object is created from the Repository call, which is passed up to the service layer. The Service layer returns a DTO via the DTO Mapper to the parent caller (the console app) and then the console app displays the customer name via a write line call.

None of these layers have any inter-dependent dependencies coded inside of them. I'm using constructor injection to inject dependencies into the calling object.

Once unity is set up, it will find the dependencies and supply them to the program at runtime. Therefore, if I need a ICustomerRepository for the service layer to work properly, Unity will give the Service layer a CustomerRepository instance. Since CustomerRepository inherits from ICustomerRepository Unity is able to make this link (once you've set it up) and supply the proper instance.

Class Diagram

 

The Setup & Code

The easiest way to see HOW Unity works is to get into the code. My recommendation is to download the sample below, fire it up in Visual Studio and set some break points to see how the code is interacting. Seeing is believing!

Before Unity can supply your application types at runtime, you have to tell Unity WHAT you want it to supply and where to find it. This can be done multiple ways as described here. Today we will go over manual configuration inside of the console app, and xml configuration.

Manual Configuration

The manual configuration that I've utilized here utilizes the fluent interface of the container.

Explanation of code: Here we are telling Unity to register a type. We're saying "If someone requests ICustomerRepository, give them an instance of CustomerRepository. If someone requests ICustomerDTOMapper, then give them an instance of CustomerDTOMapper. ..." and so on.

 

 

Using the Container From Manual Configuration

After you've set up the types of objects the container should resolve, you can then ask the container for a instance of "ICustomerService" and then invoke a method call on it. At this very point in time Unity will give you the CustomerService, and then when the customer service needs a repository Unity will then give it a instance of CustomerRepository, etc. At this point in time, everything is mapped for you behind the scenes. The only thing you have to do is ask for the first object and Unity will walk the dependency graph and fill in the blanks for you (if as long as you've given Unity the proper types it needs).

Here's how to do this in the code:

 

 

 

XML Configuration

XML configuration utilizes an external XML file (app.config/web.config) to create its dependency graph. This allows for a lot more freedom in what you would like to do with your app. If you're not happy with a certain version of "ICustomerRepository" you can create a new one, drop the DLL in the bin folder and change this config file to point to the new one and you're done. No recompiling!

In this implementation I'm using the app.config file because this is a Console App for example purposes. The full schema for XML configuration can be found here on the MSDN.

To utilize the XML configuration you'll need to utilize a custom config section. You can do this by placing this code into your config section of your app.config file:

Next, you'll need to add the container and type definition as shown below (this is just a snippet, full code is included at the bottom of the post):

The container gets its types from the config file at runtime.

Each type is declared in the config file as the "type" of object to find and the "mapTo" defines which object to return when the "type" is requested.

The type definitions are declared as type, assembly.

 

 

 

 

 

 

Using the Container From XML Configuration

To force Unity to use the XML Configuration you have to perform few extra set up steps in the application code as shown below. Essentially you're telling Unity that it's configuration/mappings are stored in a config file. The config section configures the container for you, as shown below.

To have Unity resolve an instance, its the same as the manual configuration option above. Here is the same image from above that displays how to do this:

 

 

 

 

Conclusion

Overall, using Unity as quite simple for this example. The docs on MSDN were pretty good, however I didn't really like the examples that were contained with the download because they did not show you how to utilize XML configuration as I wanted to. It didn't take but a few minutes to figure out what I needed to do. I think Unity is a decent solution at this time. I plan to investigate further into the depths of Unity to see if it may possibly be an alternative for my favorite container tool, Windsor Container.

 

Download The Code For This Post

FooTheory.UnityExample.zip (~477K)

Having worked on quite a few teams where I've been the lead responsible for helping implement TDD or been an Agile Coach - I've seen a group of habits develop when teams first start utilizing TDD. These are ...

 

1. No test isolation

All functionality that is being tested is in one test. Tests are heavily over specified.

How to fix: Spend some time pairing with the developers that are having the issue. Help explain why we want to break tests apart into smaller units, aka: "UNIT" tests. Let them know that we do not want to test the entire class in one unit test. Just because it can be done doesn't mean it should be done. Ya know, I COULD drive into oncoming traffic, but its just not a good idea. :)

 

2. Failure to recognize the TDD Mantra 

Most  new TDD'rs will go from Red to Green to - I'm done! Nope. I'm sorry guys, we have one more in that list - Refactor. Let's say it together.  Red/Green/ReFactor, Red/Green/ReFactor :)

How To Fix: Help the developers realize that we want to refactor for a reason. We have a passing test, we know what to expect from our results. Now lets clean up our code, maybe introduce some interfaces, change some variable names, introduce some fields, extract some methods, etc. Doing this allows us to clean up the code as well as have the confidence that our changes did not muck up the expected result. Run the unit tests after you refactor. If it breaks, oops, lets go figure out WHY it broke. We caught the error early, its a lot cheaper now. :)

 

3. The previous lends itself to Insufficient Test Coverage/TDD is my new Debugger

The developers usually will do enough to get the test passing and then move onto the next task. They think of TDD as a new debugger.

How To Fix: Sit down with the developers that have this issue and explain: Just because we can now unit test a method/object and step through it with a debugger doesn't mean that this is the new debugger.  That's not the point. Just because the test passes doesn't mean we're done. Just because your method passes if you pass a valid object into it doesn't mean that its fully tested. What happens if I pass a null object into it? What happens if I pass a new'd up object with nothing instantiated? Have those instances been tested? Have we tested that our objects are interacting as we expect them to? Do we know if the Logger got called? How do we know if we didn't test it?  That its the classic question: How do we know it works, if we don't have a test to prove it?

 

4. No concept of separation of concerns or IoC/dependency injection.

This is not a big deal and I expect it of most new TDD converts. Usually while learning TDD the first few tests do not need DI/IoC, but this is something that will help in the future and will need to be understood to really grasp. This really comes into play when we start separating our concerns and breaking dependencies between objects. The refactoring that takes place here can really get deep into DI/IoC sometimes.

How To Fix: Give them a great intro into interfaces and how they're used. Show them great articles on DI/IoC written by Martin Fowler, Jeremy D. Miller, Ayende, and have them join certain mailing lists such as altdotnet to join in/read the discussions. On that list alone, DI/IoC discussions occur on a daily basis.

5. TDD Complaints

I've seen complaints such as:

1. It takes too long to write the tests
2. I write more test code than real code.
3. The tests are harder to write than the real code.
4. How is this going to help me get my project done? I can just hit F5 and test it and I can tell if it works or not with my own eyes.
5. Who cares if it passes a unit test, I'm the only person who works on this project.

How To Fix: This is one of those habits I've seen in every place I've coached. These are classic examples of someone who hasn't "seen the light" of TDD yet. In my experience, the easiest way to help them see the light is to pair with with them while writing unit tests. They will instantly see why the unit tests help them and the team. Every single time I do this I help the TDD newcomer realize that by writing this test they've exposed X bugs that they didn't think about before. It usually goes like this: "Ok, that test passes, what would happen if an empty string was passed into this? Would the DB accept an empty string?" Them: "Oh... good point, I didn't think of that." Instantly lights start turning on. Another thing that works great to help developers see the light is to ensure that you're utilizing Continuous Integration such as CCNET, or TeamCity. Have them create a unit test for a section of code. Check it in. Watch it build and watch unit tests pass. . Then have them change the code (the code which is under test) and ensure it returns a different result. Maybe it returned a user's name, such as "bob", now have it return the users name with some characters appended to the end of it, such as "bob123". Have them check it in, watch the build fail because the unit test failed. Explaining to them that this helps catch errors before the product is live is crucial. Once they have the "Ohhh!! I get it now moment", they won't want to stop writing tests.

Microsofts SharedView has been around for awhile now and at this point is in Beta. Scott Hanselborg posted about the tool just recently and I finally gave it a spin yesterday with another coworker.

I was very impressed with the smoothness of the application and I really loved how each user was given their own mouse cursor with their name attached. They were not controlling the session, but they were allowed to move their cursor around. This is very nice to have because you can see what everyone is looking at when they're talking. Very nice.

I know there are many other tools out there, but I think this one might be a one for Development teams to embrace. I've used RealVNC before for Pair Programming sessions at previous clients, but sometimes I found it choppy and the display was horrendous at times (depending on network latency). I didn’t encounter these issues with SharedView at all.

If you're looking for a new remote tool, or maybe you're just trying to show Mom how to burn a CD of photos, check out SharedView.

If you realize SharedView is not for you, check out some of these other collaboration Tools (some free, some not-so-free):

I recently help set up a CI (Continuous Integration) environment using CC.NET (Cruise Control.NET) at a client that I'm at. We're in the process of implementing TFS (Team Foundation Server) but until some red tape is cleared we're still stuck on VSS (Visual Source Safe).

While setting up the environment we were given a test VSS account to work with until everything worked as expected. Well the user they gave me had a blank password.

Example -

User: ccnet Pass: (no password)

The visual source safe source control block looked like this:

<sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
   <executable>C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE</executable>
   <project>$/CCNET</project>
   <username>ccnet</username>
   <password> </password>
   <ssdir>c:\repos\</ssdir>
   <workingDirectory>c:\myBuild</workingDirectory>
   <culture>en-us</culture>
   <cleanCopy>false</cleanCopy>
</sourcecontrol>

When I fired up the CC.NET Service, everything started off fine. The project said "Checking For Modifications" and then it HUNG there, forever. It never stopped. I had to stop the service and then kill SS.exe (source safes process).

Solution

The reason this happened is because of this line:

   <password> </password>

The password was left as " ". It was a space. If I fired up VSS and typed in ccnet and put a space into the password, it would let me in, no problem. But if I did that with CC.NET SS.EXE would hang.

Pretty much, here's what's happening - Source Safe is firing up and its trying to log in and its giving an invalid password. SS.EXE is trying to raise a dialog box, but its running under the context of the Cruise Control.NET service, therefore it cannot open that dialog box.

I changed the password field to this:

   <password></password>

and then it worked flawlessly.

 

Simple solution to a simple mistake. :)

I'm not going to lie, I'm a NUnit guy. I've used it for years. But just recently I've decided to start using MSTest. I run Team Suite and I've been using it for some basic integration and functional tests, but not full on TDD. Well this weekend I embarked on a task that utilizes full on TDD and I decided to make the jump and try to do it with MS Test.

So the first thing I had to do was reference and import Rhino Mocks. I then ran the test real quick (I had a test that did not depend on mocks yet) to make sure nothing in the import broke it (it shouldn't, but hey, I'm ADD when it comes to this TDD business). To my utter amazement, something broke. I was seeing red.

This was the beautiful error:

Microsoft.VisualStudio.TestTools.TestManagement.ExecutionException: Test Run deployment issue: The location of the file or directory '(path omitted)\main\Source\SharedBinaries\Rhino.Mocks.dll' is not trusted.

WTF? It's on my local machine. It's not a file share, hell, its even included in my project in my SharedBinaries folder. WTF MAN!?

After some looking around, I was able to figure it out.

If you download a DLL from the Internet, or get it in an email or where ever and you saved it to your disk (including a DLL in a zip too) it has some extra info attached to it called an "AES" file. (see my reference below for more info)...

To fix this annoying issue, go to the DLL, right click and then click "Unblock". See the screen shot below. Once that is done, your test will work.

 

Source: MSDN Forums

As developers we're constantly inundated with requests like this ....

• Can you add a button that does does ________
• On this screen _________ I need to have a chart of ________ displaying data ...
• I need a report that shows me _________
• Can we add _______ to this page?
• It shouldn't be too hard to add this, its just a field on the screen .... (then they explain what its supposed to do)...

(classic scope creep)

Prioritization

The order in which a developer prioritizes items in their "todo" list is often determined by the urgency placed on them by their direct managers (or higher ups). More often than not we find a high level executive or decision maker wants a feature implemented because they "think" it will add value to the product. Again, more often than not, the executives theory of how this feature is a viable request has no data to back it up. Therefore a feature is implemented with no verification that its a needed or requested feature. Please remember, this doesn't always fall upon the shoulders of the decision makers... as developers we're enamored with making things sparkly and shiny. If we think of a cool new "hot key" that we can add to our app, we'll do it, even though it might take four hours to implement, we're confident it will be the feature that saves the world.

Uhhhhh, Nope. Afraid not McFly.

 

What's the root of the issue?

We need to ask ourselves a simple question....

Question: Is this feature a vitamin or is it a prescription?

Before we can answer this... lets look at some simple definitions...

Vitamin - A supplement that helps you, its good for you, its nice to have, but its not required.

Prescription - Medicine that helps you. Its required, it helps you survive.

 

Answer: It depends. (the classic developer answer... well... it depends... :)   )

 

The Process of the Request

When an feature request comes in you need to ask (as well as the client who requested it) ...

Is this feature/request a Vitamin or a Prescription?

This is the same as asking...

Is this feature request a "nice to have" or a "requirement to survive"?

This is going to determine if the request is worth putting into the system immediately. If you have 10 tasks, ask this question ten times and  you might some up with something that looks like this:

(This mimics a fake Online Order Management system - for example purposes)

As you can see, we see that everything on the LEFT is a requirement for the system "requirement to survive" (prescription). Everything on the right is a "nice to have" (vitamin).

We may need graphs of data, but we don't need 3-d graphs. We may need Web Access to the Order Management System, but we don't need a Silverlight implementation to get this project to work. It would be "nice to have" a Silverlight implementation, but its not required.

Conclusion

The next time you're asked to implement a feature, ask yourself...

Is this a vitamin or a prescription? Then put it in that bucket. Then, once that's figured out, go into the prescription bucket and prioritize those upon business requirements. Then, when you've taken all of your prescriptions (all of those items are complete), ask yourself if the "vitamins" are going to add value to the project. if they are, then ask that question again (is this a vitamin or a prescription).

This ultimately comes down to an agile type of development process. We should only be implementing the things that add value and that are required for the app to serve its purpose. Most of the time a lot of these "Vitamins" will never make it into the system because its just not cost effective or necessary. Eventually some vitamins will make it into the system and sometimes its these Vitamins that make your system a step above the other systems, but this cannot be established until you've taken all of your prescriptions. If you're sick and bed-ridden, you can't take muscle vitamin supplements to get muscles big. You have to take the prescription to get well, then you can take the muscle supplements to get muscular.

Next time you get ready to implement a feature/request - ask yourself ...

Is this a Vitamin, or a Prescription?