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

Too many times in our lives as developers, we feel that in spite of our talent, skills and knowledge we just can't seem to bootstrap ourselves from the mess we're in. It reminds me many movies (and the great Prison Break television series) where you see a nice, innocent guy put into jail with a bunch of murderers and rapists. After stabbing a guy in order to prevent from being stabbed, our hero gets into more trouble than he started with. This vicious circle goes on and on so by the end of the movie, you are not sure what he could have done different. His skills, talents and knowledge were thrown away, replaced by the need to survive. In many scenarios in life, I feel like that guy.

Avoiding the (really)poor analogy of un-unit-tested\unmanageable\coupled\you-name-it software to jail, I decided to stand up to the challenge(talk about "What not to do") raised by my friend, Uri Kalish, and share with you my vision regarding top mistakes I have experienced in the last few years. If it will able 1-N (see, I just had to be all geeky about it, even after talking for a full paragraph on jail and murderers) of you guys & gals to change 1-Z things in your world, this post will worth any future creepy comments I'll get from real ex-prisoners (what?! there must be some ex-prisoners .Net, Java frustrated coders out there, right?).

• "Promoting" best coders into solely management positions
  It is the fear of losing someone and the way our community treat one's status causing this behavior. To make things worse, in most of these scenarios, the company (somehow)feels obliged to let him\her* manage 4-5 people so there is no fat chance he'll write code in the coming 2-3 years. I believe that this is the top-1 fatal mistake companies do. They are losing their most talented, most efficient programmers without the right adjustment and natural growth by the rest of the team. The way I see it, this is what a Team Leader should be responsible for:
  • Code for at least 60% of his time. Not 20%, not 30% and most definitely not 50%(this will cause him to fall back into 60%-40% manager). Great war leaders were great warriors, always on the front of their men. If you prefer to be left behind(technology speaking), managing from above, you should not be a Team Lead.
  • Get to know your people - what do they like to do after work hours, what are their hobbies, write down their birth-dates so you could buy them something symbolic. Make them feel like home. Spending 10+ hours in the office is more than most of us spend in our home. Notice how a very cheap gesture may change your team's world - some people like fancy keyboards, some(I'm included) prefer a big LCD screen and others prefer an extra bonus. Let's say that you invest up to 500$ per person, the ROI is still tremendous(try to think your hourly cost and how fast you'll return it). People will have everything they need(=want) in their office. Google is famous of hiring the best just because of taking care of the small details.
  • Manage your team's time - help to set the deadlines per sprint\iteration, but more important - analyze the team's productivity by picking up time estimations and actual time spent, and perform some calculation via various tools to understand the bottlenecks your team experience. Make them see, make them witness of how they can become more productive with the right set of exercises.
  • Be a mentor by leading the team with daily improvements. Change the way they think, blow their mind with new stuff. Direct them to "home reading" that you know they'll enjoy. Make them excited! Be a great developer for them.
  • Shield your team members from political business. Make sure no one is interrupting them meeting the deadline.
  • Meet the deadlines. Don't afraid to speak your mind when things are out of track. Make them see you've got what it takes to lead them back to the right path. Tough love may create great developers with the right amount of genuine caring.

         This will allow the Team Leader to remain an efficient programmer and the team grow into the new situation.         
 

• Big teams
  Team size should never be more than 4, where preferable(IMHO) is 3. We want our Team leaders to write code, remember? Managing more than 2 people other than yourself will make your TL too busy to code. Even worse, big teams will cause team illness:
  • No matter of how much good-will exists in the team, keeping many people in the loop is simply too much overhead. It will wear off your teammates.
  • This will divide the team into smaller "virtual" teams, each one is built around a user story or a complete feature.
  • Now it's getting hard to know when you're breaking things for others as no one is really into your teammates code or requirements.
  • This leads us to the most unwanted behavior - no one in these virtual teams is an expert on their domain as the team switch context all the time to meet the big team deadlines. Context switch and lack of domain experts will kill you team. From inside out.

         Keep your teams small. Managers should sync the small teams and keep the eye on the ball for them. This is their skill, their talent.

• Waste valuable time on the wrong tasks - skills .vs. tasks impediment
  This one really gets me. How many times you've been asked to do something you know you shouldn't have assigned for? Giving a c++ hardcore hacker to write HTML is silly(at best). Now, I can relate to the feeling managers have assigning these tasks  just to keep the deadlines but this shows of lack of creativity rather than good leadership. For example, the c++ hacker will cost around ~X5 then a young talented designer (by young I mean 16 years old cool dude that's doing it from age 11). Hire someone, even for a few hours a month and let the them do their magic. From some reason, managers never thought about hiring a graphic designer to write hardcore c++ code, right? It will be amazing to measure the ROI you can show your bosses even after 2-3 iterations just by putting the right players in the right positions. The same goes about database, system administrator, (customer)documentations etc. Stop treating someone's time as equal to someones else time. hardcore multi-threading guru will not enjoy a full day or two of playing with HTML to fit different resolutions. Be creative and make the adjustments! 

I have a lot more rants and tips but I'll leave it for further posts so be good and stay out of software jail.

^[*] - I'm sorry but writing him\her all over the place is plain crazy. You know I'm no sexist