What's hot ? (and I mean really ...) - scroll down for more
1).  Code Templating - advanced usage of delegates & generics: my slides & demos are available for download! CodeProject article is also available.

2).  My series "TDD in the eyes of a simpleminded" is in progress(including code!): preface, part1, part2, Q&A 1, Manual Stub .vs. Mock Stub

3).  TDD Workshop: SeeCompass v0.1 and v0.2 are out.
# Friday, April 13, 2007

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:

Posted by Oren Ellenbogen 
13/04/2007 06:26, Israel time UTC+03:00,     Comments [0]  | 
# Monday, April 09, 2007

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 ;-)

Posted by Oren Ellenbogen 
09/04/2007 01:19, Israel time UTC+03:00,     Comments [4]  | 
# Wednesday, April 04, 2007

One of my favorite C# 3.0 features is Extension Methods. In short, it ables you to extend an existing type with additional behaviors. For example, you can consider to extend the type System.Int32 (aka "int") with a new method named IsEven.

The syntax is quite trivial:

namespace Lnbogen.Extensions
{
    public static class Extentions
    {
        public static bool IsEven(this int i)
        {
            return ((i%2)==0);
        }
    }
}

Notice the "this int" which means "I want to extend the type int".
Now I can write the following code (fully IntelliSense-d and compile time checking):

using Lnbogen.Extensions; //<- this will load the extensions, it won't compile without it!

... void TestIsEven()
{
   int num = 5;
   Console.WriteLine(num.IsEven());
}

What's going on behind the scenes is quite simple, the compiler got a little "smarter" and now knows to look for Extension Methods in the imported namespaces. I don't want to elaborate too much about the syntax and requirements as Anders Hejlsberg makes it all clear in his MSDN video: C# 3.0: Future Directions in Language Innovation.


Let me direct you to the  real  meat:


Extension Methods is going to change the way we enhance "already used" code. Up to now, looking at that need (for backward compatibility), Microsoft suggested to create an interface and an abstract class that implement this interface. This allows us to extend the abstract class simply by providing new virtual members without breaking the code. The problem in this solution is that things were getting out of sync really fast leaving our interfaces shy & dry(=out of date), just to avoid breaking changes. Even worse, due to the fact that multi-inheritance is forbidden, inheriting from the abstract class pretty much slammed the door on most of our design choices. 

Let's face it; Interfaces were programmer's nightmare(before you hack my blog and delete this post, bare with me). On one hand, we're reluctant to implement an interface with 10 members as we prefer to finish our tasks in this century but on the other hand, we want our interface to expose as much API as it can to allow easy usage for its customers(=programmers) and to avoid casting it(the interface) to "specialist" interfaces.

Well, Extension Methods allows us to extend any type. Do you get my drift here?
You can now enhance any interface you've ever exposed thus making old interfaces incredibly strong. You can define a lightweight interface(easy for the implementor of the interface) and extend its abilities without breaking any existing code(enrich the customers of the interface). This is exactly what Microsoft did with LINQ. They have extended IEnumerable<T> with many Query methods such as "Select", "From", "Where", "GroupBy", "Join" (and much more...) to enhance it with a great set of new methods while still keeping the original interface untouched. All we have to do is simply import System.Query namespace.


Brilliant.

.NET | C# 3.0
Posted by Oren Ellenbogen 
04/04/2007 07:01, Israel time UTC+03:00,     Comments [2]  | 
# Sunday, March 04, 2007

 15417-23PY.jpg

We've just received an email describing the agenda for Purim day here at Mercury.
It goes something like:

" Register for Purim disguise competition(M1 building)
(You can be painted for free ; -)

... [ some more text goes here ] ... "

The first thing that came up to my mind was "Oh shit, it won't compile, she forgot to close the second )".

 

Happy holiday everybody!

 

Posted by Oren Ellenbogen 
04/03/2007 01:59, Israel time UTC+02:00,     Comments [1]  | 
# Wednesday, February 21, 2007

Assuming that you're running it from the same directory the .csproj file exists in (using Visual Studio 2005 Command Prompt):

msbuild wapProjectName.csproj /p:Configuration=Release

msbuild wapProjectName.csproj /target:_CopyWebApplication /property:OutDir=c:\SomePath\
  /property:WebProjectOutputDir=c:\SomePath\ /p:Configuration=Release

copy bin\*.* c:\SomePath\bin\

Enjoy.

Posted by Oren Ellenbogen 
21/02/2007 11:26, Israel time UTC+02:00,     Comments [1]  | 
# Thursday, February 15, 2007

If you write a blog and love to talk about code\architecture\funny customers\funny programmers\funny [you name it], you've got a chance to talk the talk and chop the chops.

Date: 21/02/2007
Time: 21:00
More details here.

I'll be there.

Posted by Oren Ellenbogen 
15/02/2007 09:46, Israel time UTC+02:00,     Comments [0]  | 
# Monday, February 12, 2007

In one of our screens, we have a list of items on the left pane and "details" screen on the right pane. The details pane appears only when one of the items is selected. If no item is selected - we show some sort of empty pane that describes the usability of the screen and ask the user to select an item in order to continue.

In order to switch between the details\empty panes, I draw two span elements and played with their visibility property. The controls are partially rendered which means that if the user did not select an item, no "details" controls or rendered and neither their validators. The problem is that ASP.NET register the validators only once (via ValidatorOnLoad() method) and on the first time the screen is rendered, the controls are not there yet (no item is selected by default).

The solution was pretty straight-forward, I think. I've downloaded a simple call to my javascript method so the validators will be re-attached again:

ScriptManager.RegisterStartupScript(this, this.GetType(), "HookupManuallyToValidators", "ReRegisterValidators();", true);

And the javascript method:

function ReRegisterValidators()
{
   if (typeof(Page_Validators) == "undefined")
      return;

   var i, val;
   for (i = 0; i < Page_Validators.length; i++) 
   {
        val = Page_Validators[i];
        ValidatorEnable(val, true);
   }
}

1-0 to lnbogen .vs. asp.net

Posted by Oren Ellenbogen 
12/02/2007 05:09, Israel time UTC+02:00,     Comments [1]  | 
# Saturday, February 10, 2007

There is a big set of posts about this issue lately. From Ayende's Can you learn to program better? and What can make a great programmer? to Phil Haack and his Better Programming By Programming Better to Jeff Atwood and his How To Become a Better Programmer by Not Programming and many others...
Well, they are all great developers and they all give us a great view for what is a great developer and how can you become one(or realize that you already are, for that matter). I like the way Jeff sums it up:
" You won't-- you cannot-- become a better programmer through sheer force of programming alone. You can only complement and enhance your existing programming skills by branching out. Learn about your users. Learn about the industry. Learn about your business. "

I agree with all of them about the HUGE leap each great developer should take from being a good developer into a great developer. Not many have done it, although I believe that many more can. I'm not sure if you heard about Ron Clark, his story is an amazing demostration of true passion to bring the best out of people. Ron managed to take a bunch of kids from Harlem, those that no one believe in them, and make them one of the best classes in the US. In his first lesson, he wrote on his board: "Dream Big! Take Risks!". He manged to direct his students with his 55 rules and teach them how to become a great human beings before everything else. It's a story about how to get everyone around you excited, driven to extract the very best out of themselves.

In my point of view, great developers are the one that really into code because they love it and because they want to make the rest of us guys better. They possess Ron's Passion to make everything better. The software they are building and the guys that are involved in doing it.

I tried to come up with my "rules" that helped me progress and influence others in the last 7 years:

  1. Be proud of your work - The most important rule I give others - Love your job, Enjoy code, Appreciate elegant solutions and let them be your inspiration.
  2. Be Eager to learn - In order to become one, you must learn the "55 rules", the foundation of your progression bar. Ayende says it best:
    " At any rate, what I am trying to say is that you need to act. Doesn't matter what you do, you need to keep pushing your knowledge until extra knowledge is easy to absorb. ". Always have a list of things you would like to know. Clear some time for you in order to progress. baby steps.
  3. Write it all down - It will take you years to understand why X is "better" than Y. Why writing logic inside a stored procedure is not always the smartest thing(or why SP is not the best way in common\simple scenarios), why it's important to unit-test your classes or why loose-coupling is that important. Following only ideas from others without suffering from your mistakes will keep you always a mediocre\good programmer at best. I have started my world with Data-Access-Layer written manually, then generated it and only then using some sort of ORM tool for this task. I've learned so much in the process that "spending" years at each phase made me understand better the way I work and the way I want to work. It was worth it. I don't encourage repeating others mistakes, I just want you to follow your heart. There are mistakes worth repeating, if it will improve you and make you releaize things about yourself.
  4. Seek for better ways to solve things - In time, you'll see a lot of recurrent patterns in your code. The way you write your application tiers, your data-access, your database, your sql, your security handling, your logging mechanism, how you integrate with other applications or how you create a solid framework. In time, you'll see a lot of recurrent thinking you were used to. Only in time you'll know how to solve code duplication in a proper manner, how to build a smart API and how to estimate your mission so you'll meet the deadline without staying at work for 14 hours a day.
  5. Don't be afraid to get credit for your work - remember, be proud of your work. You deserve it. Take ownership!
  6. Be proud of your people - Your people will make you progress or stay put. It is simple as that. 
  7. Share your knowledge - I remember that a good friend of mine talked with me about whether is should help others at the office on the expense of his time. He felt that writing code for others will make them progress on his expense. I could relate to his thoughts, but I strongly disagree with him and that's what I told him: Teaching others is the best way to take the next step. Make sure you educate others, it will make them easier to give you back. I believe that this ability and willingness to teach distinguish the great ones from the good ones. If you really want to progress from being a programmer to a Team Leader\Architect\Adviser\whatever, you would need your co-workers support, right?
  8. Find a mentor - find someone at work that will make you work harder just to so they would be proud of you. I call it the "work-daddy syndrome". It is much easier to motivate yourself if you know that someone expect greatness of you. My parents expected that I'll be great from the first day I could remember myself. They never pushed me too hard or made me stress. They were there for me when I needed them. Always with something good to say to calm me down. The reason I am so motivated to be the greatest programmer I can be is that I have great friends that expect it from me and I had the pleasure to work with my mentors and get their feedback to push me forward. I want to make them proud.
  9. Be a mentor for others - All my life I thought that I am blessed with great family, great friends and great co-workers because I manged to contribute to others. I allow myself to feel this as I know that I do my best to contribute others, to make my surrounding feel that we're heading for a better place. That we will actually be there soon. Look hard and find someone that you can see the potential in him, and if he\she let's you, help them to become better. There is no better feeling that getting a big Thank You. I'm hardly a religious guy, but I feel it easier to except good surprises in life due to good acts on my side. If something terrible happens, I know that I have a good place to fall into, that I'll bounce back.
  10. Enjoy life, it's yours - leave a funny comment in your code, don't be afraid of saying geeky comments, laugh about your\others old code. Laugh as much as you can. People will follow you if you'll know how to make them smile when things are hard. Coding can be a bitch, great programmers makes you forget it for a while.

Good luck, I know you can make it. 

Posted by Oren Ellenbogen 
10/02/2007 02:55, Israel time UTC+02:00,     Comments [4]  | 
# Wednesday, February 07, 2007

I'm doing one of the most complicated UI I've ever did(ASP.NET). In the process, I need to generate tabs(via MultiView control) pragmatically and for each tab render a tree-like checkboxes. All based on external xml. Yami.. ;-)

Reading a little about how to add dynamic View to MultiView control made me realize that I need to do my magic on the page's PreInit event. This one was quite easy, I've override the OnPreInit (I could register to the event in the page constructor, but this is easier) and called my dark voodoo "BuildTabs" method. All is good.

Now, Adding MasterPage to the blend made me puzzled for a few minutes. It seems that the page's controls are not initialized on the PreInit phase if the page has MasterPage. After I got my eyes back on the screen, stop nodding with disappointment and taking my head off the wall, I used my built-in behavioral program:

pre-think (short phase ~Thread.Sleep(1000*60));
while(no solution yet) { 
   try;
   think;
}.

2 minutes later I found the trick:

protected override void OnPreInit(EventArgs e)
{
   base.OnPreInit(e);
   base.Master.Init += new EventHandler(Master_Init);
}

void Master_Init(object sender, EventArgs e)
{
   BuildTabs(); //we must draw it from scratch on each post-back.
}

Now the controls are initialized and I can program in peace.

Posted by Oren Ellenbogen 
07/02/2007 11:47, Israel time UTC+02:00,     Comments [2]  | 
# Saturday, February 03, 2007

http://urikalish.blogspot.com/2007/02/beam-me-up-scotty-copy-and-paste-human.html

Talking about building solid, trustable enterprise applications...
gosh, this makes you think about real-time applications in a different perspective right?.

After you're done wiping, read *this dude's blog.
He is a good friend of mine and a teammate at Mercury, and by god, he knows how to write and he's never boring!

* I call him T-Bag(no physical similarity, just a private[for now] joke), but he's also known as Uri Kalish ("the man and the legend").

Posted by Oren Ellenbogen 
03/02/2007 09:06, Israel time UTC+02:00,     Comments [0]  |