One of the principles behind Agile Team, is the commitment of the Team to finish the planned features for a given iteration. There are times when some members in your team will finish their tasks early while others will stuck on unplanned or underestimated tasks. In a perfect world, each one of your teammates would be able to perform any kind of work whether it's design, writing database queries\commands, program, create graphic interface, test. At least to some degree. On the Agile community, these kind of people are called "generalist specialist". This will allow the Team to help each other and keep their commitment. In most of these scenarios, the teammates will help each other as a natural process of feeling as one unit. But things are more complex.

The problem is that you still want to hire a great SEO specialist, a great web designer or a great DBA, so this leaves you with the question "how could they help the Team meet its commitment?". We can't ask a SEO specialist to write multi-threaded C# code, which leaves us with a Team and a bunch of consultants that try to aid the Team hold to its commitment. I've seen this behavior of "consultants" inside teams leading to the notion of "Look, I've actually finished my tasks successfully! it was the Team that failed...".

Could we really try to use our SEO guy for multi-threading tasks? most probably not. The trick here is to find a common ground so we can bound our SEO guy into several fields, making him feel as part of the Team. For example, the SEO guy can make some web design by helping to create a SEO-correct HTML (thus helping to take some pressure off from the web designer) or maybe helping the architect design the user interface. One of the things we're doing now at our Team, is introducing our beloved DBA(Shlomo - I'm waiting for your blog dude) into writing the data-access layer in C#. We're doing it step by step, while I'm trying to explain about working methodologies and doing some pair programming. It will take us time (baby steps), but we'll get there.

This change in state of mind is not easy, but it is crucial if you want to jell your teammates into one Agile Team. Notice that I'm writing "Team" rather than "team". I see Team as a single entity, a solid force driven to hold to its commitment no matter what (while still keeping high quality delivery, of course); This is very different from a team, driven to do as much as it can, each one on its own, without being responsible for the greater good.

Being a part of something bigger is a motivation boost you shouldn't underestimate. For me, there is no bigger satisfaction than taking ownership over an entire application (instead of "I've fixed problems 1 and 2 in product A and problem 5 in product B"), working hard and making it work at the end of the day. Doing that, you could honestly say "I'm responsible for the success of our product, and I'm damn proud of it!".

Every new application we're trying to raise from scratch, especially when it's a big one, we're drawn to the basic questions of how to structure our code so it will be easy to maintain, easy to extend and easy on the eyes(= it makes sense). This post is meant for teams with more than 4 programmers working on the source of a 2+ (human) years project. If you work alone and the client doesn't really care, heck, you can do it in one big assembly and name it [your_name]Rules.

I've discovered along the years that it really bothers me to see unorganized solutions or bad naming. I call it "structure smell" and as you might have guessed, I'm a sensitive guy. I've structured my thoughts about the way I see things so I could use it later on as a reference for myself and for my Team. Before I'll continue, keep in mind that most of these questions are philosophical, so there is no one holy answer, it's just a matter of point of view. I tried to point out best practices based on my experience. In addition, instead of writing user-story\feature\requirement\bug fix\UI change\you-name-it, I would use the term "task" instead. I'll even go one step further and say that a given task should be limited to 0.5-1.5 days so it would be easy to see progress over time(if you're on the agile boat as I am) and help us focus on the domain\context we're working at during the task.

Enough said, let's get going:

"Should we build one big solution?"

The immediate answer on this one is absolutely not.
The quick reason behind it as no matter what you do, while working on a task, you usually don't need all of the projects at the same time. I see no reason to compile so many projects if you're working only on 2-3(or even 5-6) of them at a time. I know that Visual Studio .Net is smart enough to avoid needless compilation of projects that we're not changed, but keep in mind that John, your teammate, is working on different tasks than you are which means that he can make some changes, checked them in and your next "Get Latest Version" might cause unnecessary compilation on your side. If you haven't noticed(who am I kidding), VS.NET can become an heavy memory consumer for big solutions, add to it our beloved ReSharper(that must analyze all of the projects in the solution to give you smart ideas), it can get quite messy.

The second reason, is simplicity. Why looking at 40 projects when you need only just a few? sure, you can collapse them or even organize them in Solution Folders(in VS.NET 2005), but it's much easier to keep the noise out.

"So How should we split our solutions and projects?"

On this scale of projects, it would not be a great idea to create projects based on layers (DataAccess project, Business layer project, UI project etc). This way, each layer(=ClassLibrary) would be filled with too many classes and in time, it will be hard to find your path in one project with more than 200 files in it. Another bad side effect for splitting the projects by layers is that it will narrow the way you think about solutions (to problems). Instead of trying to create pure OO components you'll immediately start breaking one piece into "this is UI, this is BL, this is DAL" and possibly branch your code into the wrong assemblies by cold 0 or 1 decisions. Life is one big gray CLR.

So I'll try to define the way I see solutions, projects and namespaces and how should we use them:

1). Solution represent a domain in your application.

Domain is a complete sub-system in the application. It's much bigger than a single component and it's usually bind a list of components into one large sub-system that we can address as one big black box. The sub-system expose interfaces to other sub-systems in the application.

If I had to develop Lnbogen's Calendar for example, I would consider these sub-systems: Common, Engine, DataStorage, Site, Widgets. Each one of these sub-systems deserves it's own solution.

2). Project is a component in that domain or a mini-sub-system in the application.

A component is a all-around solution in a specific domain. The consumer of the component expect it to perform its task from A-Z even if that requires some of interaction with other objects. It should be transparent to the component's consumer. Let's say that we have a Calendar component, I would like to be able to call myCalendar.CreateNewMeeting(user, [meeting details]...) without taking care of insert it to the database, update some sort of cache(if exists) or to trigger alerts manually in case of collision. I expect the component to provide a full solution to my problem. Obviously, we don't expect the Calendar to save the meeting to the data storage by it's own but rather to receive some sort of IDataSource that will take care of it, but that should be made behind the scene as the purpose is to expose complete functionality.

In addition, a project might be "Entities" or "Utilities" where in these scenarios, the project represent a mini-sub-system.

3). Namespace group components and types under the same domain or "logic context"

Namespaces allow us to group types that are logically belong to the same domain and create a proper hierarchy so the programmer could easily find is way around the available types.

"What about naming?"

Naming is crucial for a few reasons: (A) It ables us to quickly understand the purpose of an assembly\class\method as its consumers, (B) good naming of classes\methods => less documentation => more 1:1 between your docs & your code and (C) it helps you to keep the most important principle of coding - be proud of your (and your team's) code. It's a beautiful thing to see Semingo.[...]. I'm loving it!

Naming rules:
1). Name your solutions by the domain they represent.
2). Name your projects by the components or mini-sub-system they represent. Template: [CompanyName].[Application].[ComponentName\MiniSubSystem]
3). Name your namespaces by the domain they group (the types) by.


Example (Lnbogen's Calendar):

Directories tree:

- Lnbogen
 - Calendar (root Directory)
   - build
      - v1.0
      - v1.1
      (etc)
   - tools
      (list of assemblies, exe or other 3rd party components you might use)
   - documents
   - db
      (maybe backup of database files for easy deployment)
   - src
      - Common
         | Common.sln
         - Lnbogen.Calendar.Entities 
         - Lnbogen.Calendar.Entities.Tests 
         - Lnbogen.Calendar.Utilities            
         - Lnbogen.Calendar.Utilities.Tests 
      - Engine
         | Engine.sln
         - Lnbogen.Calendar.Framework
         - Lnbogen.Calendar.Framework.Tests
         - Lnbogen.Calendar.TimeCoordinator
         - Lnbogen.Calendar.TimeCoordinator.Tests
         - Lnbogen.Calendar.RulesEngine
         - Lnbogen.Calendar.RulesEngine.Tests
         - Lnbogen.Calendar.Service ^(*1)
         - Lnbogen.Calendar.Service.Tests
      - DataStorage
         | DataStorage.sln
         - Lnbogen.Calendar.DataStorage.Framework
         - Lnbogen.Calendar.DataStorage.Framework.Tests
         - Lnbogen.Calendar.DataStorage.HardDiskPersisenceManager
         - Lnbogen.Calendar.DataStorage.HardDiskPersisenceManager.Tests
         - Lnbogen.Calendar.DataStorage.WebPersisteneceManger
         - Lnbogen.Calendar.DataStorage.WebPersisteneceManger.Tests
         - Lnbogen.Calendar.DataStorage.DatabasePersistenceManager
         - Lnbogen.Calendar.DataStorage.DatabasePersistenceManager.Tests
         - Lnbogen.Calendar.DataStorage.Service ^(*1)
         - Lnbogen.Calendar.DataStorage.Service.Tests
      - Site
         - Lnbogen.Calendar.UI
         - Lnbogen.Calendar.UI.AdminSite
         - Lnbogen.Calendar.UI.UserSite
      - Widgets
         - Lnbogen.Calendar.Widgets.Framework
         - Lnbogen.Calendar.Widgets.Interfaces (for plug-ins support)
         - Lnbogen.Calendar.Widgets.Service
         (more directories per widget)
      - Integration
         - Lnbogen.Calendar.Integration.InternalWorkflow.Tests 
         - Lnbogen.Calendar.Integration.ExternalWorkflow.Tests (test that the services we expose to the world work as expected)
      - References
         (here you should put all the dlls that you use as "file reference" in the various solutions)
         
^*1: for example, this could be WCF wrapper of the underlying engine that enable other internal components to talk with the CalendarEngine\DataStorage as one complete component.

You can notice that I've chosen to drop the "Engine" or "Common" while selecting the name of the directories. "Common" is not really a domain but rather a logic separation of things that belong to many domains (usually all of them). "Engine" is the real deal, there is no Calendar without the engine right? So in this case I feel comfortable to drop the obvious (Lnbogen.Calendar.Framework won't sound better as Lnbogen.Calendar.Engine.Framework).

Solution structure:

In VS.NET 2005, there is a nice feature named "Solution Folder" (right-click on the solution->Add->New Solution Folder) which is a lovely way to group projects. The Solution Folder is a virtual folder(you won't see it on your HD) so you don't have to get worried about too much nesting. 

Here is the pattern I love to use, demonstrated on the Engine.sln:

Engine (Solution)
   _Core (Solution Folder) (*2)
      - Lnbogen.Calendar.Framework
      - Lnbogen.Calendar.TimeCoordinator
      - Lnbogen.Calendar.RulesEngine
      - Lnbogen.Calendar.Service
   Tests (Solution Folder)
      - Lnbogen.Calendar.Framework.Tests
      - Lnbogen.Calendar.TimeCoordinator.Tests
      - Lnbogen.Calendar.RulesEngine.Tests
      - Lnbogen.Calendar.Service.Tests
   ExternalComponents (Solution Folder)
      - Lnbogen.Calendar.Entities (via "Add existing project")
      - Lnbogen.Calendar.Utilities (via "Add existing project")
   3rdPartyComponents (Solution Folder)
      - (Open Source projects that I might use will go here)
   Solution Items
      (add any dll that you use as file reference in this solution)

^*2: The reason I'm using "_" is to make sure it's the first Solution Folder. I just think it's more productive way of looking on your projects. I use the same thing for my interfaces and call the file that contains them _Interfaces.cs.

On the next post, I'll try to focus on strong naming and versioning of assemblies.

This title encapsulate a lot of changes in my life.

Leaving Mercury\HP

After less than a year, I had to make one of the hardest choices in my life and decided to resign my position at Mercury after receiving an opportunity to join a baby(we're looking for offices now) startup named Semingo. Mercury is a great home for developers; The quality of the people there is beyond anything I've seen in the last ~8 years, the projects are challenging, the clients are demanding and the amount of investments the management put in the teams is unimaginable. No wonder why Mercury was bought for the huge price of 4.5 billion dollars by HP. Putting the clients first, hire great managers, non-stop training and fetching the best programmers available is a bullet-proof path for success.

The hardest part was leaving my friends there, but I know that I'll keep in touch with them. I said goodbye to the guys in a small gathering so I want to leave it private, but I do want to thank you all again for sharing your life, your ideas and challenges with me:
Hagay, Number, Big Guy, Jersey, Nicos, Rico, Master Jedi(Doron), Moti, Jonit, Chonga, Maya, Mininberg, Alon, Chik Chik, Abergel, Oleg, Mizrahi, Ravit, Sefi, Lidor, Zini, Arie, Ifat and the rest of the guys there(I hope I did not forget anyone :|) - goodbye and good luck. I love you all.

Joining Semingo

This was an offer that I just could not say no to. The project is inspiring, the scale and size are unimaginable, the team is built from a group of young(avg. ~25) "hackers"(my nickname for highly talented workaholic developers), great technology, great management. All the right cards. In addition, and this one is crucial - I'm 23 years old so this is a great(maybe the only) time to work 14-18h a day without paying alimony\psychotherapist. I'm sure that it will be very interesting ride. 

At the moment, I can't say much about the stuff we're doing except that it's a very challenging web 2.0 project.
I promise to publish more about the team, work methodologies(agile\scrum) and technical experience later on...

Leaving my home, renting an apartment:

I'm looking for an apartment in Herzelia\Herzelia Pitouch, close to the our future office. If you know a guy that knows a guy - please send me an email! ;)

Gosh, it's going to be one hell of a year!

I had just resolved a very ugly bug in one of our screens. The behavior was the following:
You open a the page and click on a "cancel" button that closes the current screen and refresh the parent screen.
So far all is sweet.
Now you do it again (open & click "cancel")
So far all is sweet.
Try to open any other page.
gosh! nothing works! Everything got stuck somehow...

The cancel button was declared like this:

<asp:Button id="..." runat="server" OnClientClick="RefreshParentAndCloseMe();" />

Can you spot the problematic approach here?
Button.AutoPostBack is set to True as default which means that clicking on the button triggered page submit but at the same
time we run javascript code to close the window. My guess is that the server gets a new request and handles it but the client
is dead until then(until the response is ready).
Playing with this behavior can lead to unexpected behavior (in our case - we had to close the browser and start over)

Solutions?
  A. Use html button (I prefer this one as this pure client behavior button)
  B. change the OnClientClick to: OnClientClick="RefreshParentAndClose(); return false;"
  C. Set AutoPostBack=False on the button.

Damn, it was so much fun to play a little with TDD and abstract the lousy API given by Microsoft to register client-side script. I'll write about the process and design changes I've made due to testability reasons. TDD is a great design tool, it's amazing to witness the "before" and "after" of your code, all because of the requirements to test things separately.

Here are a few API samples, taken from the Demo project (you can play with it and see the results):

Keep in mind that I'm only supplying a different API (abstraction) of Microsoft's implementation. In order to accomplish that, I'm using Windsor to wire the ClientSideExtender with the new ajaxian ScriptManager(supports UpdatePanel), which will actually be responsible to register the script under the hood. You can look at the web.config (under the <castle> element) for more details.

Source:
Lnbogen.Web.UI.zip (253.56 KB)

Thank God, some may say, that bananas are still way too expensive to replace human developers with apes; Well, at least by Uri Kalish in his Why Software Engineers Should Care About the Price of Bananas. Let's face it, we have too many "chumps" out there, lurking to make a few extra bucks by faking it really well. But every once in a while, the sun is shining in glorious colors and you meet a really talented developer whom you think will be a great addition to your team. You ask her logical questions, she shoot right back with pearly answers; You ask her to design something and bang, she nails it; You ask her to juggle with code a bit and it is all sweet. She has analytic mind and just enough experience. Total Package.

This leaves you with the one thing, the only thing, that really matters - how can you tell whether or not she will use her analytic mind to solve your team's problems instead of introducing more complicated ones while trying?

I came to the conclusion that the only way to know how skilled a developer is, is by letting her solve a very simple problem and shoot more problems to the air while she solves it. Skilled developers will be able to break things into smaller chunks and solve them in a SIMPLE manner. When I say simple, I mean it, it will be so simple taht even a chump will be able to read it. Then they will move on to the next problem and solve it in the same SIMPLE way they did before. Then they'll tell you how to sew the all thing into one wonderful solution. It's actually pretty straightforward, simple things are easier to combine, but only a few folks out there knows how to "break & build" in a graceful, simple manner.

I look way back to my first days with .Net and OOP and I can honestly say that I did it all wrong(although it looked damn right at the time). If you looked at the code, it was elegant, in its own way, it was "sophisticated"(interfaces, events, a few Design Patterns) but it wasn't right. It wasn't SIMPLE. I had too many classes with too many (wrong) responsibilities, some of them contained quite a few God Methods and they were in no way testable. I had a great amount of green words(aka comments) to explain why things "needed" to be complex.

So for the developers among you - read, talk, write, teach and most importantly practice. Continue to improve your skills by breaking tasks into smaller chunks and keep making them green-free. If you spend more lines on documentation, you're on the wrong direction. Invest time in breaking responsibilities to different classes(class should have a very narrow responsibility) and take the time to think about your API. I'm playing quite a lot lately(Fluent Interfaces, Creating a decent API for client side script registration) with method names and the benefit I see in it is huge. readable API requires almost no documentation at all. Adding testable code to the equation and you're definitely on the right track.

For those of you out there that interview people - if you think this is it and you finally found someone - let him\her solve a few problems and focus about how simple is it to read the code, to refactor it, to extend it. How much documentation is required to explain the solution to the rest of your team?

What do you look for when interviewing skilled developers?

Phil Haack gives an excellent example of how to test a registration to event while implementing MVP pattern (via Rhino Mocks). If you did not read it yet, take a pause for 2 minutes and give it a look; It is worth it, I promise.

The only thing that bothers me in the example is that the need to assert the triggering of the event kind of spoiled the code. I think that in those scenarios, it's much better to use some sort of Stub and override the class under test in order to keep the it cleaner. So instead of having this code:

public class Presenter
{
   IView view;
   public Presenter(IView view)
   {
      this.view = view;
      this.view.Load += new EventHandler(view_Load);
   }

   public bool EventLoaded
   {
      get { return this.eventLoaded; }
      set { this.eventLoaded = value; }
   }

   bool eventLoaded;

   void view_Load(object sender, EventArgs e)
   {
      this.eventLoaded = true;
   }
}

I would have created something like this:

public class Presenter
{
   IView view;
   public Presenter(IView view)
   {
      this.view = view;
      this.view.Load += new EventHandler(view_Load);
   }

   protected virtual void view_Load(object sender, EventArgs e)
   {
       // production code here
   }
}


// This will go in the PresenterTests class
public class TestablePresenter : Presenter
{
   public bool WasEventLoaded = false;
   protected override void view_Load(object sender, EventArgs e)
   {
       WasEventLoaded = true;
   }
}

Now we can create an instance of TestablePresenter and Assert the WasEventLoaded field.
My guess is that Phil actually did something like this in his project and merely wanted to show an example, but I still thought it was important enough to demonstrate this separation as I firmly believe we must make sure that our need for tests will not actually hurt the design.

In my last post about Creating a decent API for client side script registration, Eran raised a few great comments about the readability and proper usage of this style of coding. I decided to answer his questions with a post, as my comment started to fill enough paper to clean a Brazilian forest or two (well, in terms of a response).

Introduced by Martin Folwer, Fluent Interfaces ables the programmer to supply an API that can be used to build a genuine use-case in the system or just a complete logical query\request from a service. This coding style is quite different from the traditional 101 lessons in OOP school. The biggest benefit of Fluent Interface, in my opinion, is that you can read the code out load like the customer is talking to you instead of the programmer that wrote it. Sometimes it gets even better, you can read someone's else code like she\he was next to you, explaining what she\he meant do do. My take is that using a method to describe use-case\action\query\request will be (almost)always better, in terms of readability, than using parameter(s) as you'll need the IntelliSense to understand the latter. Here is a simple API, the first one is traditional OOP while the second one applies Fluent Interfaces. Please bare in mind that these samples were written just to set the ground for the difference between these two coding technique:

// take 1 - traditional style
public class ClientSideExtender
{
    public void CallMethod(string methodName, RunAt runScriptAt, bool ignoreExceptions, params object[] parameters);
}

I'll start my post with a question:
What's the difference between ScriptManager.RegisterClientScriptBlock and ScriptManager.RegisterStartupScript methods?

Well, the only way to find out is not by looking at the method names but rather to look in MSDN. According to MSDN the former registers your script after the <form> element while the latter is registering your script just before the </form>. Now, let me ask you this - how the word "Startup" can be interpreted as "end of page"?

So OK, the naming is really bad but what's even worse are the arguments of these methods:

public static void RegisterClientScriptBlock(Control\Page control\page, Type type, string key, string script, bool addScriptTags);
public static void RegisterStartupScript(Control\Page control\page, Type type, string key, string script, bool addScriptTags);

Now, most of us write this code 95%(+) of the times:

I don't understand the real need behind creating a "unique" key from the type+key given to this method. Why not creating a unique key each and every time? You need to create a simple API for the common (90%) tasks. I almost never actually asked about IsClientScriptBlockRegistered. But enough complaining, time to write a few bits & bytes.

I tried to play with the API a little and here is what I came up with (it's merly the beginning, I'll update on my progress during the week):

The Fluent interface gives it a nice "read-the-code-like-a-story" look&feel which makes things really easy to understand. There is no thinking here, the code says it all.

Another rant I have is that all of the API examples I've demonstrated so far are implemented although not fully tested as using Microsoft classes requires a lot of work in order to abstract. The funny thing is that they(Microsoft) have decoupled things in the new Microsoft ASP.NET Ajax library(System.Web.Extension.dll) but they made everything internal!  You have IPage, which is really useful abstraction to the Page class, sitting there as an internal member. I had to come up with some heavy abstraction to make things play nice together.

To sum up, I would really appreciate YOUR feedback about the API and any kind of suggestion or things that you would like to see in future API. I'll release the code later this week with a short demo to get you going.

Agile is really about forming 1-BIG-happy family or in geek terms: one collaborative unit of work.

If you go over most(if not all) of the practices Scrum\Agile\XP have to offer, you’ll find two things in common: how to make your customers ROI as higher as possible as soon as possible and bonding everyone together so they are ALL responsible for the ship to move forward, one step at a time, constantly. Good-will and high IQ is a (really)great start but never enough. At the end of the day, customers understand working functionality described in user stories(“I will be able to move my money between my bank accounts”) rather than functional stories(“The system will supply Web Services in order to integrate with our billing system”) and most importantly – they’ll only pay for the former. But the technologist part in me(I’m made of 70% water, 29% 0 and 1, leaving about 1% for adult context), understands that we programmers really love to solve hard problems in elegant ways. I never saw nor hear a developer jumps up and down saying something like “I made it possible to move money from account A to account B!” or “The user can now get his lost password via email!”. I just love the idea of creating a successful setup so our brilliant guys will be able to transform their IQ into business value. What a noble idea, actually making one’s talent into a fat paycheck (I’m probably the only one finding it romantic am I?). 

In many ways, gather the “right” practices for the team is like getting ready for a lecture in front of a big (important)audience. Forming a good lecture requires a lot of thinking(what do I want to deliver), preparation(how can I do it), ice-breakers\funny stories(keeping them smiling  and cooperative in the process), motivation points(keep their eyes on the ball), examples(proves that it works) and most importantly – letting your audience know what they’ll gain from this lecture(high ROI) and keeping your promise. Don’t be a fool, trying to enforce the process or make a shortcut will be like participating in a lecture where the presenter decide to write a set of articles in his slides causing you to look at the 100–inch-screen-with-1500–words-per-slide, thinking it will deliver all the data you’ll need. It never does.

How can you start making a change(including improve an already great practices)?

• Read, listen, view, try things, write notes. Play the secret agent role and try to learn your enemy.
• Let your people know about these practices. Open their eyes into new ideas.
• Explain how things will work from now on, how it will look in 2 months, 6 months, 1 year, 2 years from now. Inspire them.
• Answer their questions, make them trust in the system and trust the family.
• Detect negative workers and detach them from the team. NOW.

A little push to get you going:

• Portrait Of An Agile Development Process
• Seven Agile Team Practices That Scale
• Scrum et al (Google Video)
• On Process And Practices (Jermy Miller)
• Kanban in Action - whiteboard to the rescue, making it all visible
• Comparing Approaches to Budgeting and Estimating Software Development  Projects
• Agile Process Smells: Solution Stories
• Agile Process Smells: Waiting on Specialists
• Agile Project Planning Tips
• Tacit Knowledge - constant learning and practicing