Uri Lavi

Good Values Pay Off

2011-04-28T09:19:00.001+03:00

(Cross post from IRefactor)

To simply put, we have been acquired!
For the past couple of years we have been working hard to enhance our technological solutions, the de facto: scalable, near exact match, visual search engine. Using this visual search engine as a backbone, allowed us to envision and to develop many of our great products.

Not surprisingly, PicScout not only became the market leader in the image copyright solutions, but also provided unique solutions in the terms of crediting every image on the web.

On a personal note; Serving as a VP R&D during this time, building the architecture, driving the technology and working with the greatest team ever - was remarkable and enjoyable. I am happy to be a part of a great team where professionalism matters and which employs many of the Software Craftsmanship values, I so deeply encourage!

A few moments ago, we have officially announced that we (PicScout) have been acquired by Getty
Images.

I am sure that our unique technological value will continue to benefit to the world of images.

One small step for a man, one giant leap for mankind

2011-02-24T20:51:00.000+02:00

(Cross post from IRefactor)

Lately I had a lot of thoughts about how to introduce a change within an organization.

For a while now I am giving some talks about leading a software development team, focusing each time on a different facet, such as: Quality, Architecture, Recruitment Process and etc...
(I have combined some of those thoughts into a short lecture, which I entitled Fostering Software Craftsmanship (Building Successful Teams) and it is given as a part of the IL Tech Talks).

But here is a phenomena, I encounter each time.

Most of the audience understand the importance of the concepts, but really struggle with introducing them to their organization.

Martin Deutsch

Writing Unit Tests will lengthen my development time!
How much time should I "reserve" for doing Refactoring?
How do I explain to my manager that Refactoring is important?
Code Reviews are difficult, because people have different tastes!
Code Reviews are taking too long! We will not be given the time to do it, ever!
Continuous Integration will take a few weeks to accomplish. I won't be given any time to do it in the near feature!
Those concepts are great, but the time to do them should be allocated by the management.
...

I am sure we all heard those sayings. Heck, we even have given those once! (No... Not really :) )

Though I have a lot to say and comment about each and every one of the above statements - there are some broader aspects I must cover first.

We all hate changes, don't we? Doing Unit Tests, investing our time in Refactoring (or Builds) - those are just an extra activities that we have never done (or done correctly).
One should really invest his own time in order to polish those activities and doing so is just recognizing that we need to change. As humans, we find it extremely difficult to accept changes.
Jack Welch understood it perfectly, but nevertheless he succeeded to introduce a lot of changes to GE. Jack Welch found the change to be exciting, daring and imaginative.
GE success can be rooted to its ability to change and to change fast.

However, applying change in the simplest way doesn't work.
We cannot accept the change all at once. Evolution takes its time; Therefore, in order to accept the change we also should adapt one step after another.
(It's really like Refactoring Steps: One small change at a time, compile and test).

Sometimes it takes years to introduce all those concepts to your teams:
Start by a simple task, like code conventions or source control layout, then teach unit tests and invest in teaching code smells, continue by applying rigorCode Reviews and etc... and etc...

Doing everything in one big bang just doesn't work. I have seen several teams that got introduced to Scrum or TDD in a matter of weeks. Those are big changes to somebody who didn't evolve to the "right" point. Needless to say that the failures that those teams experienced were so discouraging that till now some of those Software Engineers hate TDD and claim that Unit Tests (even not TDD) are plain waste of their time.

You shouldn't be surprised that applying all the great concepts to your organization will take years.
One step after another; One small step for a Software Engineer, one giant leap for an Organization.

Close-up of Astronaut?s Foot on Lunar Surface - NASA Images

Code Smells

2011-01-03T16:09:00.001+02:00

(Cross post from IRefactor)

If you like practicing in identifying code smells, then you can find below a short class called
TimerManager.

public class TimerManager
{
    public delegate void TimerCallback(object data);
    private static readonly object _sync = new object();
    private readonly Dictionary<int, Timer> timers = new Dictionary<int, Timer>();
    private readonly Dictionary<int, TimerCallback> callbacks = new Dictionary<int, TimerCallback>();

     public void SetTimeout(TimerCallback timerCallback, int snooze)
     {
            var timer = new Timer(snooze);
            lock (_sync)
            {
               timers.Add(timer.GetHashCode(), timer);
               callbacks.Add(timer.GetHashCode(),
               x =>
               {
                  lock (_sync)
                  {
                     var t = timers[x.GetHashCode()];
                     t.Stop();
                     t.Close();
                     timers.Remove(x.GetHashCode());
                     callbacks.Remove(x.GetHashCode());
                  }
                  // invoke function provided by caller
                  timerCallback(null);
                });
            }
            timer.Elapsed += timer_Elapsed;
            timer.AutoReset = false;
            timer.Start();
      }
}

Here are some Code Smells, that can be identified:

TimerManager (a weak smell) - Everything that is called a manager alerts me a great deal.
Usually managers are God objects, have low cohesion and high coupling and violating too much
OO principles...
It doesn't necessary mean that the same happens here, but it should be noted and then verified in the code.
TimerCallback should be generic or restricted by a Data Type.
It's better to specialize the TimerCallback with more concrete type parameter. Having said
that, it might be that the author wanted to use the built in TimerCallback in .NET.
In such a case the declaration is redundant.
static _sync object.
The class has only instance members, besides that _sync object; Will it make sense to do the following?

TimerManager timerManager1 = new TimerManager();
timerManager1.SetTimeout(...);
... 
TimerManager timerManager2 = new TimerManager();
// here timerManager2 will block on the same object as the timerManager1
timerManager2.SetTimeout(...);

Both Dictionaries are just plain procedural programming definitions; It is the same like having 2 arrays aligned by their indexes as both the dictionaries will be accessed by the same index (an int). Behold, as one mistake (accessing the wrong index) can lead this code to an undefined behavior.
GetHashCode shouldn't be used to identify uniquely an object.
Let me repeat again... GetHashCode mustn't be used to identify uniquely an object...
GetHashCode's implementation is needed for collections (and Equals, see below).
Sometimes the same result of the hash code will put two different objects in the same hush bucket - which means those are not unique identifiers!!!
Once implementing GetHashCode, the Equals method should be implemented as well.
Consider the follwoing code:

t.Stop();
t.Close();

One should be familiar with the tools at the hand.
Close() does what Stop() do and more... Calling Stop() and then Close() just makes the method a little bit longer without any effect.
When in doubt, consider to take a few moments just to review the provided API.
Redundant Remark.
The remark repeats the code, doesn't bring anything informative enough and affects the length of the method.
It can be safely removed.

// invoke function provided by caller
timerCallback(null);

Thanks to Aviv the following is of course another smell: passing null to the callback function (i.e. declaring the parameter in the callback and eventually passing null).

timerCallback(null);

The Importance of Mentorship

2010-10-02T21:04:00.000+02:00

(Cross post from IRefactor)

It's hard to become a professional. It's even harder to become a professional Software Engineer.
Last week, during a small management conference I bumped into an old friend of mine, who I didn't see for a couple of years. Being a leader of a software engineering group, he was frustrated and worried:

"I have a group of 20 people, working hard to meet harsh deadlines. The project has just started, but most of the software engineers are already not pleased. There are junior developers that consider themselves as senior developers, there are senior developers that consider themselves as team leaders and there is no uniform professional knowledge. All of these are affecting the product's quality and really hurting our work."

Although there are many ways to shape cohesive and gelled teams, there is one important notion that just lately received its attention: Mentoring.

The professional life of a Software Engineer is rather sporadic.
Most of us are drifted with the stream. The lifecycle is pretty much the same; You find a job, you receive features or requirements to implement, you code, you debug and then you move on.

But, have you ever felt that if mentored by a true professional you would succeed more?
You would know deeper. You would decide better. You would have better choices of your career paths.
I reckon that most of us did feel the same...

Moreover, good mentors, not only promote individuals, but usually create around themselves a great environment (and therefore great teams).
Excellence drives excellence and professional excellence usually directs all the team members to shared ownership, partnership and targets.

However, it is hard to find a true professional and it is even harder to find a true professional that knows how to mentor.

There are a lot of parameters that shape a mentor, but no doubt the first virtue will be experience: Experience of successes, experience of failures and experience of crisis-es.
Those are true Software Craftsman, that spent their days and nights in polishing their skills.
And being masters in building and managing software, they can teach you a lot: How to write good requirements, how to architect, how to design, how to produce clean code, how to build software, how to ship software, how to manage technological teams, how to receive better technological decisions and etc... and etc...

There is much more to say about mentoring. I will dedicate a few posts in the future, to describe what are, in my opinion, the virtues and the ways to do it well.
However in the meanwhile, I would like to take up the glove I have thrown in this post... On our next Software Craftsmanship Meetup, I will enroll a Mentorship program.

A Mentorship program will allow Mentees to find an appropriate Mentors.
The mentorship period will be for at least 4 months (IMHO, it should be more than 4 months, but let's start with that period).
During the mentorship period both the Mentees and the Mentors are committed to each other.
They will meet for at least 2 hours each week in order to:

Provide Technical Guidance and Feedback.
Provide Reading Sources.
Review and Build Carree Paths.
Hold Code Reads, Code Reviews and Pairing.
Do Architecture and Design Reviews.
Review Management Decisions and Advise Management Dilemmas
Etc. . .

If you are not coming to the 4th Software Craftsmanship meetup, but still want to participate you are most welcome to contact me via the blog.

Effective Code Review - A Presentation

2010-09-30T18:02:00.000+02:00

(Cross post from IRefactor)

Here is a short presentation I did a while ago on a Code Review process.

I am sure, there are a lot of different ways to do code review, but the following served me well in the past.

One important note to bare in mind is that a Code Review cannot take more than a few hours.
People get tired easily; It's difficult to read somebody else's logic (code) and even more: to understand and to pinpoint the problems.

Therefore the Code Review process should be effective and highly cohesive as much as possible; I like the following metrics:

Summary: Ask a Software Engineer you are reviewing to explain in bullets what are the purposes of
the application, the module or the feature you are going to review.
Top-Down: Require to review high level components; High Level Design (Class Diagram, Component
Diagram, Some other Sketch and etc...)
Understand in general what are the main components / classes in the solution.
Focus: Ask the Software Engineer to point you towards the most problematic sections of the code.
He is the one who knows best what was hard to design or to implement.
Ask him to explain what was the problem and how he tried to resolve it.
Bottom-Up: Now start from the code you focused on (You can also review the Unit Tests in order to
understand better the code's behavior).
Read and Communicate: Take an ownership on the keyboard and observe the code. Try to see whether it is easy to understand the code and to navigate through it.
During your drive you should communicate loudly what are you doing; Where you are going next (e.g. "I'm opening class X"), what you think of a piece of code you are reviewing and etc... You should ask questions in order to understand why it was implemented the way it was and also to verify that other alternatives were considered by the Software Engineer.
You should spot the following:
- Bad naming (classes, methods, properties and etc...)
- Code Smells
- Design Violations (SOLID, GoF and etc...)
- Architectural Flows
- And many others (I won't discuss here currently)...
Your mutual notes should be written by the reviewed Software Engineer (navigator) and fixed later on. Don't waste your precious time to tackle immediately the problems.

Effective Code Review

A Round Table

2010-09-28T14:24:00.000+02:00

(Cross post from IRefactor)

Here is an interesting thing about Partnership and Shared Ownership.
Once creating such an atmosphere within your team (company) you are on the road to success.

Everybody works together in order to accomplish the shared targets: Product Managers, Engineering, QA, Market Managers and etc...
Usually, small teams and small companies are characterized by the "Partnership and Shared Ownership" DNA.
But when they grow, rest assure that slowly but surely the Partnership and the Shared Ownership notion will dissipate.

Once reaching ~150 people it is almost impossible to share the same values as you did before. (And in my humble opinion, it happens much much before 150)
Ah, but then a miracle happens...
Some "smart" manager gets a wonderful idea how to revive the sense of Partnership and Shared Ownership.
He suggests to have a "round table" with the President\CEO\Group Manager.

Indeed, the President cannot meet each and every employee, but he can share a sense of equality as the King Arthur did with his knights.

Let's have a bunch of employees sitting together, discussing their important values, tasks and views with his majesty.
Alas, I have been there; Allow me, then, to elaborate regarding what really happens around this table:

Either most of the employees are not familiar with each other or are not familiar enough in order to speak from the heart.
Therefore, most of the time, the employees will introduce themselves and their projects/tasks without touching the really painful issues.
The rest of the time, the President will summarize his activities and his "successful decisions and directions".
And then... Well, then the meeting will be over. (But at least the President will be happy. After all, such a "convenient" audience is very hard to find...)

There are only two recipes to succeed in creating the Partnership and Shared Ownership atmosphere.

Involve & Trust.

You involve your employees, they involve their employees and so on... and so on... You spend your time explaining the roadmap, emphasizing values, motivating and also hearing what your people have to say. You verify that you follow what you preach; You incorporate your employees suggestions and opinions. You also give an attribution as your employees should be acknowledged if they have provided a good idea. And you provide a "safety net". Your employees should know that they have a strong figure standing behind them; You don't blame, you don't share your disappointments - you support and foster.

But sometimes, the round table idea sneaks into the small companies.

When it happens, it signals that the problem is even worse; If a manager feels that there is a need to have a round table in a small company, it means that he doesn't have the time to bestow the values on his employees. His hope is to do the minimal effort, bringing everybody in "one take" to the table, in order to "motivate". Though the employees will feel more comfortable with each other in a small company, it just emphasizes the miscommunication and the mistrust that is going on. Clearly, this is not a best management...

Dear manager: Involve & Trust... And do it personally!

Short Roman Numeral Kata

2010-08-16T09:27:00.001+03:00

(Cross post from IRefactor)

For our second Software Craftsmanship Coding Dojo, I have prepared a "Short Roman
Numeral" Kata.

In essence, a Short Roman Numeral is a number between 0 to 3999 that has a ToString() method which returns its roman presentation.
The rules of roman presentation construction can be found here.

After the meeting, I took some time in order to record the Code Kata.

As you probably know it is extremely difficult to produce a well synchronized recording.

Hence, after a few sleepless nights I have finished the recording with great satisfaction, only to discover (thank you my "dear" friend) that I made a typo during the exercise.

Despite that, I have decided to share with you the current recording and to fix the typo later on...

You can watch the High Definition version on Vimeo directly (or by pressing on "Vimeo" below)

The (complete) source code can be found here.

Writing Readable Code - Complex Object Construction

2010-04-16T21:08:00.013+03:00

(Cross post from IRefactor)

Once upon a time, there was a class called Invoice. Its responsibility was to calculate a final
price being presented to the customer.

Time went on; The autumn passed, the winter fade out and the spring was already at the door and our class started to rust.
Each time a developer found a new set of relevant parameters (that should have been passed to the Invoice class) he added a new constructor, to support them.

And so it happened, that after a while, two fellows stumbled on the class:

"What's that rusty thing, my dear?" said G.Ollum "I don't understand; What constructor should I invoke on the Invoice class? Does it matter how should I create the Invoice object? The class has more than 20 constructors; How in the world, somebody would understand what to do?"

"Let me see, what's the problem" said D.Eagol

    public class Invoice

        public Customer Customer { get; private set; }

        public DateTime ContractDate { get; private set; }

        public TimeSpan ServiceContinuum { get; private set; }

        public double BaseFee { get; private set; }

        public double ServiceFee { get; private set; }

        //... a lot of other members ...

        public Invoice(Customer customer)

            Customer = customer;

        public Invoice(Customer customer, DateTime contractDate)

            : this(customer)

        public Invoice(Customer customer, DateTime contractDate, double baseFee)

            : this(customer, contractDate)

        public Invoice(Customer customer, TimeSpan serviceContinuum, double serviceFee)

            : this(customer)

        //... a lot of other constructors ...

"It seems that you are right G.Olum", said D.Eagol after looking at the code, "You have a lot of
different constructors, each instantiates a slightly different type of Invoice object, mainly because there are a lot of optional parameters to the Invoice class. There are also required ones; Look at the Customer parameter being accepted in each and every constructor."

"Moreover", continued D.Eagol, "The world has changed and something that shouldn't have been forgotten, was lost."

"What's that, my dear?", inquired G.Olum

"Well, you cannot name your constructors. That's why it is so difficult for you to find how to instantiate
the class. If you were supplied methods with meaningful, intention revealing names then you would be able to create a required object", explained D.Eagol

"So, what can I do?", cried G.Olum

"Let's summarise what you really want to do and then see how to accomplish it", said D.Eagol

You want to:

Create a complex object, with:
- A few required parameters
- A few (or many) optional parameters

You don't want to:

Use constructors - they are nameless and we fear of them

So, let's create an internal class whose sole responsibility will be to shadow that complex
creation.
Our inner class will provide a meaningful method name for each optional parameter of the Invoice class.
The required parameters will be passed to one(and only one) inner's class constructor. Since, that inner class
deals with construction, let's call him a Builder.

Here is, how it should look:

    public sealed class Invoice

        public Customer Customer { get; private set; }

        public DateTime ContractDate { get; private set; }

        public TimeSpan ServiceContinuum { get; private set; }

        public double BaseFee { get; private set; }

        public double ServiceFee { get; private set; }

        private Invoice()

        public class Builder

            private Customer customer;

            private DateTime contractDate;

            private TimeSpan serviceContinuum;

            private double baseFee;

            private double serviceFee;

            public Builder(Customer customer)

                this.customer = customer;

            public Builder SignedOn(DateTime signDate)

                this.contractDate = signDate;

                return this;

            public Builder ServiceAgreementForPeriodOf(TimeSpan serviceContinuum)

                this.serviceContinuum = serviceContinuum;

                return this;

            public Builder ServiceBaseFee(double baseFee)

                this.baseFee = baseFee;

                return this;

            public Builder ServiceFee(double serviceFee)

                this.serviceFee = serviceFee;

                return this;

            public Invoice Build()

                Invoice invoice = new Invoice

                    Customer = this.customer,

                    ContractDate = this.contractDate,

                    ServiceContinuum = this.serviceContinuum,

                    BaseFee = this.baseFee,

                    ServiceFee = this.serviceFee

};

                return invoice;

"You see", continued D.Eagol, "That's what you have accomplished:"

The Invoice's constructor is private - only the Builder can return an Invoice, through its Build method
The Builder's constructor receives the Invoice's required parameter: Customer
The Builder provides meaningful method names for eachof the Invoice's optional parameters and utilizes Fluent interface in order to provide a more readable form of setting those parameters

"And here, how the instantiation looks like:"

 Invoice.Builder invoiceBuilder = new Invoice.Builder(Customer.CustomerA);

            Invoice invoice = invoiceBuilder

                                    .SignedOn(Date("4/7/2010 08:00:00 PM"))

                                    .ServiceAgreementForPeriodOf(Days(30))

                                    .ServiceBaseFee(1000)

                                  .Build();

"Now it really shines!", finished D.Eagol, "What do you say G.Olum?"

"Give us that, D.eagol, my love... It's my birthday...and I wants it!", gurgled G.Olum.

Refactoring Tools Review - part II

2010-03-12T12:28:00.000+02:00

(Cross post from IRefactor)

Oh, my God!
I am definitely in love!
I finally had the time to play with the latest DevExpress's Refactor! Pro and Code Rush.
Two distinct main features capture my eyes immediately:

The ability to highlight the changes/code smells and refactorings inside the Visual Studio's Editor.
It seems that the team invested a lot of effort in order to enable painting on the Visual Studio's editor and canvas.
This enables a smooth user experience, without prompting and stalling with unnecessary dialogs.
The changes are visualized directly on the source code.
Below is one of my favorite refactoring steps: "Extract Method" visualized in Visual Studio 2008.
A huge amount of automated tasks: navigations, refactoring steps and code improvements.
Refactor! Pro has more than 150 refactoring steps to automate the burden of the day to day refactoring.
Code Rush brings smooth navigation within the code, markers (like the bookmarks in VS, but they work across different files/projects), templates to enhance the development and "on the fly" static code analysis.
Below is a partial list of the Refactoring Catalog:

Here is a screenshot of a Code Issue found in the code, by the "on the fly" code analysis. Pay attention to the blue indicator being painted on the editor's scroll bar:

Navigation features and Templates allow a very fast development experience.
The CodeRush window trains and suggests interactively, templates or other actions that are applicable at the current position.

However those are the small things that make these tools so great. It's unbelievably easy to develop clean code in the first place and to refactor it later. Meet your new friend; Hit "Ctrl+`" and all your dreams will come true :)

The tools allow you to develop fast and smoothly: you will double your productivity, you will find that it is easier to navigate through the code and finally you will find that you can give up the mouse. Being a Software Craftsman it's very important to know the tools of the trade (IDE commands/shortcuts). CodeRush and Refactor! Pro can help you to achieve that. Moreover, these tools provide a good sense of living in one place. Everything is achievable through the Visual Studio Editor and accessible through one keyboard combination or another.

If you have seen my previous post, you have probably noticed the Editor layout I used in the past. Code Metrics Window, Code Definition Window and Source Length Guides hack (in the registry) were combined together to enhance the IDE. The combination, using default Visual Studio's windows, was to say the least, a bit unnatural.

Here is my Editor's layout that utilizes the CodeRush's features:

You can easily see that the code metrics are placed very conveniently adjusted to a method. The source length guides is configurable and can be easily modified (without hacking the registry) and the references window is awesome as it allows colored Code Definition Window's experience.

Notwithstanding; Though CodeRush and Refactor! Pro are great tools, there will be quite a learning curve in order to master all (or at least a great deal) of it's features. There are so many that each day I discover new and exciting ones. Therefore, in order to maximize your experience you will need to invest time learning the features. For that purpose DevExpress provides a descent help (coming installed with the tools) and also maintains a good training video series, here. In addition, as stated above, the CodeRush Window provides an interactive learning experience while you are working on your code base.

I would also suggest adding the following to the refactoring catalog:

"Move Method" - an ability to move a method to a different class/file.
Refactor! Pro provides a very close feature, called "Extract Method To Type", but there are several issues with the later:

Sometimes the method is already given, but should be moved to a different location.
Extracting a method to a different type is a combination of two basic steps: Extract Method and Move Method. Refactoring usually preaches to do small changes followed by compilation and unit tests execution. Combining those two steps can affect beginners; They can either premature utilizing the refactoring or can fail, to correctly interpret the right location for the method.

"Remove Parameter" - an ability to remove a parameter from a method's declaration.
Also here, Refactor! Pro provides a close feature, called "Remove Unused Parameter". Though, I easily can degenerate the use of the parameter inside the method and then use the "Remove Unused Parameter" step, I still find it useful to remove first the parameter from the method itself.

CodeRush comes with TestRunner and supports now several xUnit Test Frameworks.
A nice to have feature is also:

A support for a parametrized Unit Test Attribute, such as TestCaseSource.

From performance perspective, I have found CodeRush and Refactor! Pro satisfying. I didn't feel any unnecessary pauses or delays during my work, while utilizing the tools.

Finally, the most important note :). Would I consider to purchase these tools?
My answer is, it depends: As a corporate that wants to boost its developers performance, buying the whole package of CodeRush and Refactor! Pro for 249.99$ makes sense. As an individual developer, the only less expensive option is to consider a purchase of just the Refactor! Pro license for 99$. I will add, that if DevExpress will cut of the number of features in CodeRush and Refactor! Pro, but will provide a license from 50$ - 120$ it will make the individual developer's life easier.

A disclaimer: I have received a fully functional copy of the CodeRush and Refactor! Pro in order to allow the investigation of the features over the time.

Prime Factors Kata

2010-03-03T23:33:00.011+02:00

(Cross post from IRefactor)

One of the key aspects of a Software Craftsmanship is constant practice.
Kata (from Martial Arts) is one form of such practice. The notion of a Code Kata was first introduced by Dave Thomas and can be viewed as:

Practice of the same methods, solutions and activities to a perfection.
Practice of the same problem, tackling it each time from a different angle or with a different solution.

Solving a known problem multiple times utilizing the same methods, enhances the understanding of the specific steps; It especially enhances the understanding of unit tests, refactoring steps or "Design" approaches. Moreover, striving to do better each time motivates one to learn the keyboard shortcuts and IDE commands in order to perform smoothly. Knowing the tools of the trade (or the tools of the Martial Arts :) ) is essential for the Software Craftsman's success.

Solving a problem in different methods helps to identify solutions that work better in the right context (requirements).

Below (also here) is one of my Prime Factors Kata's sessions recorded late at night :).
The Kata demonstrates finding a number's prime factors using TDD (C#, NUnit, VS 2008).
(Don't forget to turn on the speakers)

I must admit, that it is super difficult to record a completely clean demonstration, especially while synchronizing the music and the moves. Moreover, one of the real obstacles is statically typed languages (C#) that slow a bit the moves. Exercising the Kata with dynamically typed languages can ease and speed the performance.

How will you find your next job?

2009-12-19T21:52:00.000+02:00

(Cross post from IRefactor)

So, you have decided to move on...

You have updated your CV and sent it to your friends... Then you sent it to a couple of recruitment companies... Then you sent it to all known recruitment companies...

After a while...
You have been called to an interview...and another one... and another one...

Weeks later...
You got a proposal(s) and you have decided to accept the job: The compensations are a little bit better than the existing ones. The issues are the same; After all you are paid to develop more or less according to your experience. Yet, you are pretty much excited about the change; You are going to work with new people and make new collaborations. Though minor, it cannot be dismissed, after all we are social "animals" and changing groups/places has its effect.

Hey, but did you stop to think for a moment whether the next place is going to be a better one? After all, that's the purpose of you moving on, isn't it?

Many posts are dealing with how to hire the best of the bests Software Engineers (and I am not an exception), but this post is dedicated to the searchers themselves.

Here, how you will find your next job:

A disclaimer:
-There are many ways to evaluate a company; I am focusing on more technological/professional evaluations using social media.
-Below is a short list of criteria, followed by my explanations of why those criteria identify a better company.

Learn the company's executives bio:

Who are its managers (Company's Web Site)?
Were are they mentioned (Google, Techcrunch)?
- How often are they mentioned?
- Do they mention their technologies/products vision in a clear way?
- Can you identify a company's future roadmap?

Search for the company's profile (If not available, search for employees profiles): (Linkedin, Facebook)

Look for the current and former employees, are you familiar with any?
Look for the current employees profiles:
- What is their average experience?
- Do they have any professional blogs? If yes, then:
- - Do they deal with Software Architecture and/or Design?
  - Do they discuss innovative ideas in terms of Software Engineering or Software Management?
  - Do they contain any posts explaining company's software application development decisions?
  - Do they emphasize/teach how things are being done inside their company?
- Does any of the employees lecture (occasionally or regularly) on Software Engineering topics? (Given that the company isn't a professional training company)
- Does any of the employees contribute to an open source? ( Linkedin, Google, Codeproject, Codeplex)
- Does any of the employees attend (occasionally or regularly) any professional conventions (Linkedin Events, Linkedin Groups, Google Groups, Twitter)

Search for the company's additional activities:

Does the company support an open source? (Linkedin,Google, Codeproject, Codeplex)
Does the company contribute to an open source? (Linkedin,Google, Codeproject, Codeplex)
Does the company support any professional event?

And here is why, in my opinion, the above criteria will help you to identify the better companies:

Good executives will create a lot of buzz around their company, either by being cited by others or by expressing themselves through press, articles, blogs or tweets (A good example is: Joel Spolsky and his columns here: joelonsoftware).
Though this is expected, clear definition of the technologies/products with consistent and proven history of achievements, symbolizes higher success of the company's roadmap (and future).
Moreover, such executives, usually create a supportive climate where Software Engineers thrive. In such a climate, Software Engineers are driven by mutual success in terms of products and technologies.
Good Engineers, in their turn, usually blog or tweet about their professional experience.
Real good Engineers not only discuss a specific technology, but also discuss much wider aspects like Architecture, Design and Software Management. You will have a lot of fun learning and working with such, especially if you spot the following concepts in their posts: S.O.L.I.D principles, Test Driven Development (TDD), Unit Testing, Continuous Integration and Static Code Analysis (also here). Those are the signs of people who care about high quality products!
The best Engineers contribute to an open source. They spend their spare time coding and refining their professional knowledge (also here). Not only they enhance themselves, but they also contribute a great deal to others (that's the beauty of the open source). Be sure, they will also contribute to your knowledge and skills when working with them.
Thus, being technologically thirsty, those Engineers will attend professional conventions and events and eventually will drive their companies to support such activities.

Remember, it may seem like a long and tedious investigation, but it pays back, if you really aim to find a great place to work in.

DTOs, Business Entities and Persistency

2009-10-24T21:49:00.017+02:00

(Cross post from IRefactor)

When designing an application, one can easily confuse DTOs, Business Entities and Persistency.

Using the following simple examples I will demonstrate design considerations and thoughts that will dispel some mists.

Consider that you want to represent an audio or a movie located on a web page.
When you visualize such an object, the first thing you probably see is the data that characterizes it. No surprise here. You applied, without knowing it, an "Information Expert" pattern when you visualized the object's knowledge responsibilities.

So, what are they? Clearly such an object will have:

Uri - object's URL
Content - object's content
DateCreated - object's creation date
Etc...

I will name this object a "Resource", since it represents a resource being located on a web page (be it a movie or an audio).

But wait... here you go; Meet the DTO object. A DTO is a simple container for a set of aggregated data that needs to be transferred across a process or network boundary. It should contain no business logic and limit its behavior to activities such as internal consistency checking and basic validation.

The Resource object is rather simple, it's a mere placeholder for the object's attributes and as such represents a DTO.
Now, let's say that a Resource object should be persisted to some store.

Basically, we would like to introduce a "Save" functionality that will persist a Resource object. The question is: Who's responsibility should it be? Using the Information Expert pattern again will reveal that functional responsibility (as a "Save" operation) is a sole responsibility of a class with the most information required to fulfill it. Hmmm... Isn't it a Resource class? As a Resource class "knows" exactly the information it wants to persist, it implies that the Resource class should have the "Save" responsibility.

I know... I know... Didn't we say a minute ago that a DTO shouldn't contain any business logic? By adding a Save responsibility to the resource class we turned it into something else. We turned the Resource into Business Entity. A business entity is an object that is responsible to solve domain requirements by collaborating with additional business entities.

Let's see what are our design options for creating a Resource business entity.

Option I: A Resource business entity inherits a ResourceDTO.

Though it's tempting to select the above solution, you shouldn't take the path (unless the requirements are very very simple). Remember; One of the principles of object oriented design is to favor object composition over class inheritance. There are many reasons for which the principle holds, but I am not going to discuss all of them here.

It does not make sense that Resource "is-a" type of ResourceDTO; You are not going to transfer the Resource object across boundaries. Moreover, such a design may violate the Single Responsibility and Open Closed Principles. The "Save" method is going to be bloated with a specific logic of how to connect to a certain store - which is clearly not Resource's responsibility. Changing a store, having more than one store or changing what to store will require Resource modifications - which violates the OC principle.

Option II: A Resource business entity passes a Resource DTO to a specialized Resource data access entity.
All the specific logic of data access is captured in a specialized ResourceDal object. Any change in store, will change only the specialized object. The ResourceDal object will receive a Persistent Resource DTO object, thus decoupling the Resource entity from the persistent information (which can vary easily later on). Such a design is superior as it allows to inject the correct data access object to the Resource entity (and it also means that it will be much more testable). Also, it allows to have multiple DTOs, for example: one for persistency and one for visualization.

In order to derive a PersistentResourceDTO from a Resource entity I will use an AutoMapper library.

AutoMapper uses a fluent configuration API to define an object to object mapping strategy, thus allowing easy transformations.
Here is the PersistentResourceDTO declaration:


[Serializable]
public class PersistedResourceDTO
{
 public Uri Uri { get; private set; }
 public byte[] Content { get; private set; }
 public DateTime DateCreated { get; private set; }
}

Using AutoMapper library is especially easy when the properties and methods of the source type match to the properties of the destination type - this is called flattening.
Thus ExtractPersistentDTO method's implementation is simple and coherent.


private PersistedResourceDTO ExtractPersistentDTO()
{
// creates a mapping between Resource and persistent Resource DTO.
Mapper.CreateMap<Resource, PersistedResourceDTO>();
// flattens the current Resource object into PersistedResourceDTO.
PersistedResourceDTO dto = Mapper.Map<Resource, PersistedResourceDTO>(this);

return dto;
}

AutoMapper library also allows to project a mapping. Projection - transforms a source to a destination beyond flattening the object model. Consider that a Resource also has a collection of keywords. In order to visualize the Resource we want to use the following VisualResourceDTO where the title will be a combination of all the keywords.


[Serializable]
public class VisualResourceDTO
{
public Uri Uri { get; private set; }
public string Title { get; private set; }
}

Here is how to do it using the AutoMapper:


private VisualResourceDTO ExtractVisualDTO()
{
// creates a mapping between Resource and Resource DTO        
Mapper.CreateMap<Resource, VisualResourceDTO>()
      .ForMember( d => d.Title,
                  op => op.MapFrom(resource => 
                            string.Join(" ", resource.Keywords.ToArray()))
                );
// projects the current resource object into VisualResourceDTO
VisualResourceDTO dto = Mapper.Map<Resource, VisualResourceDTO>(this);

return dto;
}

(Remark: In the post above I didn't discuss other approaches, like ORM solutions).

Notes on C++/CLI

2009-10-04T22:18:00.020+02:00

(Cross post from IRefactor)
If you asked for my opinion whether to develop an application using (unmanaged) C++, I would strongly advise you to reconsider.

Unless you deal with real time applications (or near real time applications), you should better utilize the managed world. Sure, there are times for old good C++; especially when the application's memory footprint is an issue, but needless to say, you have better chances in productivity, ease of development and maintainability in the managed applications (C#, Java and etc...) than in the unmanaged world.

Sometimes, obviously, the above advice is impractical. When dealing with complex algorithmic issues, which already have pretty sound support in various unmanaged C++ toolkits and frameworks, you are forced to choose what exists over reinventing the wheel.

C++/CLI can bridge the gap.
The common practice is to wrap the unmanaged libraries with the C++/CLI, thus exposing the unmanaged functionality through the managed C++ layer. In the example below, Taxes project contains various algorithms for tax calculations written in (unmanaged) C++. The Taxes project is wrapped with TaxesMixed project which is a C++/CLI project. Finally, TaxesApp project, which is written in C#, uses the TaxesMixed wrapper to utilize the complex unmanaged tax calculations.

When dealing with unmanaged, mixed (C++/CLI) and managed projects, there are some notes to keep in mind:

Debugging

If you want to debug the unmanaged code (e.g.Taxes above) from the managed (e.g. TaxesApp above), don't forget to mark the option enable unmanaged code debugging on the debug tab of the managed project's settings.

Implementing Destructor/Finalizer

C++/CLI classes that use unmanaged C++ classes should implement Dispose\Finalize pattern (look for: "Deterministic finalization template" title). Apparently, implementing the pattern is much easier using C++/CLI than C#. All you need, is to provide a deterministic destructor (~ syntax) and a finalize method (! syntax) and everything else will be generated by the C++/CLI.

TaxesMixed::TaxCalculatorWrapper::~TaxCalculatorWrapper()
{
    this->!TaxCalculatorWrapper();
}

TaxesMixed::TaxCalculatorWrapper::!TaxCalculatorWrapper()
{
    if(nullptr != m_Calculator)
    {
        delete m_Calculator;
    }
}

C++/CLI will generate all the additional Dispose, Dispose(bool) and Finalize methods in order to complete the pattern.

Here is a quick peek into the Dispose(bool) method, using Reflector.
As you can see, the method calls the deterministic Dispose method (~) when the TaxWrapper.Dispose() method is called and calls the Finalize method (!) when the TaxWrapper is garbage collected.

To pin or not to pin?

When a pointer to a managed object (or its part) needs to be passed to the unmanaged code, there is one important issue to be aware of:
Managed objects (on CLR Small Object Heap) don't remain at the same location for their lifetime as they are moved during the GC heap compaction cycles.
As a consequence,a native pointer that points to a CLI object becomes garbage once the object has been relocated. In order to ensure a correct behavior, C++/CLI introduces a pin_ptr pointer which pins a CLI object in order to prevent its relocation while a garbage collection cycle occurs.

(If you need a pointer semantic in C++/CLI you can use an interior_ptr pointer which is updated automatically when a garbage collection cycle occurs and remains a valid pointer even after the compaction.)

You declare a pin_ptr as follows:

pin_ptr<type> = &initializer;

Example:

public class Person
{
    public string Id {get; protected set;}
    public double[] Taxes { get; protected set;}

    public Person()
    {
        Id = "SSN:12345"
        Taxes = taxesDal.Load(this.Id);
    }
}


void TaxesMixed::TaxCalculatorWrapper::CalculateAnnualTaxes(Person^ person)
{
    //Pinning a whole object. 
    pin_ptr<Person^> ptr = &person;
    //Passing the object or one of its value members to a native code.
    . . .

    //Pinning an array (by pinning the first element). 
    pin_ptr<double> arrPtr = &person->Taxes[0];
    //Assigning to a native pointer 
    double* arr = arrPtr;
    . . .
}

When dealing with pin_ptr you should remember:

Pinning a sub-object defined in a managed object has the effect of pinning the entire object.
Pinning an object also pins its value fields (that is, fields of primitive or value type). However, fields declared by tracking handle are not pinned.
(To avoid redundant mistakes, my suggestion is to always pin the required reference type member, thus pinning the whole object.)
A pinning pointer can point to a reference handle, value type or boxed type handle, member of a managed type or to an element of a managed array. It cannot point to a reference type.

In any case, if you are interested in reading more about C++/CLI, you can find here very good tutorials on the topic.

Refactoring Tools Review - Part I

2009-09-05T23:06:00.019+03:00

Cross post from IRefactor

Don Roberts and John Brant stated in the book Refactoring - Improving the Design of Existing Code:

"Refactoring with automated tool support feels different from manual refactoring".

Indeed - It is!
Having an automated tool that helps you to change the code without the fear of breaking it - is invaluable.

That's why, I wanted to summarize several available options for .NET developers.

Let's start with the obvious one: Visual Studio Refactoring Tool.
As usual Microsoft concentrates on the core business, leaving the field to other players.

Visual Studio Refactoring Tool

Visual Studio comes with a very simple Refactoring Tool, available from the Refactor
toolbar or from the Refactor context menu.

As you can see, all the refactoring steps have keyboard shortcuts.
In addition, Visual Studio triggers some of the aforementioned refactoring steps behind the scene, when a certain change is detected.
Those changes are mostly underlined with a double red line, as here:

Using the combination Shift-Alt-F10 will fire the correct refactoring step menu, allowing smooth and quick refactoring.
(In the case above - Rename refactoring step).

The Refactoring Tool provides pretty basic refactring steps:

Rename -
The tool effectively changes the names (variables, methods, types and etc...) across projects in the same solution.
The changes can be easily reviewed (checked/unchecked) prior the modification through the Preview Changes menu.

Extract Method -
Visual Studio provides a basic method extraction mechanism. Extract Method generates a new method with correctly inferred parameters (from the extracted scope) and substitutes the extracted block code with a call to the method. In addition, Extract Method identifies whether a method uses local class members and if not, suggests marking the extracted method as static.
In the Refactoring process this often indicates that the method should Move to a different class, but Visual Studio Refactoring Tool doesn't provide any suggestions to where such a move is possible.
(There are other tools that do provide the suggestions - patience, patience...).
Encapsulate Field -
Creates properties for existing members.
Extract Interface -
Enables extraction of an interface from a type.
Promote Local Variables to Parameter -
Promotes a local variable to a method's parameter.
When a local variable declaration isn't selected correctly, the tool will prompt with an explanatory menu (first screenshot).
Also, the tool will alert when it cannot guarantee that all the callers pass a legal value to the newly promoted parameter (second screenshot).

Remove Parameters/Reorder Parameters -
Adjusts a method's parameters.

Clearly, as stated above, this is a very simplistic refactoring tool, especially when comparing to Eclipse. As you can see below, Eclipse comes with much more refactoring steps available out of the box.
There are more than 20 refactoring steps in the Refactor menu.

In addition, one can utilize additional Visual Studio "Refactoring" features.

Visual Studio Additional "Refactoring" Features

Source Code Length -

Adding Guides to the Vusial Studio IDE will allow to visually emphasis the length of the source code line.
In order to add Guides, you should edit the "HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\X.X\Text Editor" key in the registry (where X.X is the VS version).
Create a string key called "Guides" with the value "RGB(255,0,0), 80" in order to have a red line at column 80 in the text editor.
Code Definition -
Using the Go To Definition each time you want to examine the referenced method or type is very tedious. That's why the Code Definition Window is handy! As you move the insertion point in the editor, or change the selection in Class View, the Object Browser, or Call Browser, the content of the Code Definition window is updated and displays the definition of a symbol referenced by the selection.
Code Metrics -
Knowing the code complexity can help writing a more clean and refactored code. Visual Studio provides the Code Metrics Window that provides a better insight into the developed code. I would suggest to pay attention especially on the following metrics:
1. Cyclomatic Complexity - Measures the structural complexity of the code.
  A program that has complex control flow (and thus a high cyclomatic score) will require more unit tests to achieve good code coverage and will be less maintainable.
2. Class Coupling - Measures the coupling to unique classes through parameters, local variables, return types, method calls and etc...
  High coupling (and thus a high class coupling score) indicates a design that is difficult to reuse and maintain because of its many interdependencies on other types.

Here is the combined IDE view with all the additional "refactoring" features:

Of course, an experienced Software Engineer can create a clean and refactored code, even with the skim Visual Studio Refactoring Tool and additional "Refactroing" features. The experience though isn't going to be smooth and easy. The refactoring features are scattered and as overall not so user friendly.

Summary:

The Visual Studio Refactoring Tool is rather simplistic.
Most used refactoring steps are: Rename and Extract Method. Those steps provide fairly good functionality (though extra behavior is possible when extracting a method).
Other significant refactoring steps don't exist; Microsoft leaves the stage to other players.
Additional refactoring features, as: Source Code Length, Code Definition and Code Metrics exist and provide complementary ways to understand and refine your code. The features, though, scattered across different places which makes it hard to simultaneously work with all of them.

In the next post we will examine additional automatic refactoring tools.

One pattern to rule them all

2009-07-26T22:46:00.005+03:00

(Cross post from IRefactor)

Well, there is none...
Simply to put, there is no silver bullet.

Yet, while designing an application, there are several well known extremes:

"Heavy weighted design" - Such a design will use almost each and every pattern described in the bible of "Design Patterns" - by the Gang of Four.

However, squeezing as much as possible patterns into your design has a bad smell. Here is what Erich Gamma has to say on the matter:

"Trying to use all the patterns is a bad thing, because you will end up with synthetic designs-speculative designs that have "flexibility" that no one needs. These days software is too complex. We can't afford speculating what else it should do. We need to focus on what it actually needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.

"Big ball of mud" or "no design" at all - Though the application utilizes classes (objects) and methods, it does it solely due to the language constraints. After all, the code must be placed somewhere and usually it lies in giant classes and methods. Besides that, there are no abstraction layers or small and specialized objects that have "concise conversations" in order to solve the business requirements.

To use the patterns correctly, a Software Engineer must understand the context (=requirements) and the suggested solutions depicted by the patterns. Usually, in the real life scenario, it's hard to grasp where exactly is the right context to which a suggested design solution should be applicable. Especially for the inexperienced Software Engineers, design patterns described by the Gang of Four's bible can confuse and lead to:

Misidentify contexts and thus creation of "Big ball of mud" or "no design" applications.
Over identify contexts (even where there is no context at all) and thus creation of "Heavy weighted design" applications.

That's where the Expert pattern can be handy! Expert pattern is one of the General Responsibility Assignment Software Patterns. In essence it's a very basic and straightforward pattern that helps to pinpoint what is the main responsibility of a method or a class. Just ask yourself: "What is the real responsibility of the method/class? Is it really this method's/class's responsibility to do that operation?". By answering those questions it's possible to divide a system effectively to a lot of small, but cohesive objects, that really need to collaborate together in order to solve your business requirements (which is what Object Oriented Design is really about).

So it comes, that though there is no "pattern to rule them all", using the Expert pattern/principle effectively, will allow you to rule your application.

Asymmetric Accessor Accessibility and Automatic Properties

2009-07-12T21:21:00.006+03:00

(Cross post from IRefactor)

Asymmetric Accessor Accessibility – is a feature that was introduced in .NET 2.0 in order to allow different accessibility levels to get and set portions of a property or an indexer. Those get and set portions are called accessors.

In the example below, the get accessor is public, whereas the set accessor is restricted and private.

private string id;
//...
public string Id
{
get { return id; }
private set { id = value; }
}

Automatic Properties – is a syntactic sugar feature, introduced in .NET 3.5 to allow more concise property declaration.

public string Id {get; set;}

The above features, can be combined together to form a very elegant and concise property declaration, with asymmetric accessibility levels:

public string Id {get; private set;}

Using “automatic asymmetric accessibility properties” contributes to the clarity, elegance and correctness of the code.

One of such examples is immutable class implementation.

A Cult Programmer

2009-06-12T18:16:00.005+03:00

Cross post from IRefactor

Last week, while conducting interviews for a Senior Software Engineer position, a candidate asked me a “red alert” question. A few moments after starting the interview and explaining the position, the candidate squeezed the following:

“What is the current .NET framework you are using and are you planning to move to .NET 4.0?”

I bet you wonder… Is it really a “red alert” question?

Allow me to elaborate. The candidate’s real motivation was to percept how technological is the company that interviews him. If the company is stuck in .NET 1.X or it isn’t planning to move forward with Microsoft’s future plans, it just not technological enough.

What alerts me is the idea that the specific version of framework used by the software is a measure to the software’s quality and not using a specific technology necessarily means something bad. Maybe the company utilizes the best practices of Software Development by applying: Analysis, Architecture & Design, Automatic Unit Testing, Static Code Analysis, Code Coverage, Integration Tests, Automatic Tests, Automatic Builds, Code Reviews, Peer Programming and etc… Maybe the company stands for writing quality software by applying the Object Oriented Principles like GRASP (loose coupling / high cohesion), Design Patterns, SOLID and etc…
Maybe somebody forgot that a good quality software doesn’t mean necessary using the dynamic keyword?

Allow me to emphasis. Technology is important! Choosing the right technology for the specific requirements of your application is important!
However, a technology is not the key factor in the software’s success.
It reminds me a good article discussing the technology leaps, by Joel Spolsky. Jumping from technology to technology seems to be just a plain “Fire and Motion”.

If you are asked whether you are planning to move towards .NET X.X, just ask the candidate to explain, why (or what) in his opinion moving to .NET X.X will contribute to your application. Most of the time, as in my case, the answer will be quit generic: “It’s just a better technology”. This clearly, as explained above, doesn’t stand! Such a candidate is being marked often as a cult programmer. A Cult Programmer is a programmer who seems to compensate sound Software Engineering skills solely with a specific technology evolution.

Separate Domain from Presentation – part III

2009-05-30T23:49:00.022+03:00

Cross post from IRefactor

This is a third post in the series of posts about “Separate Domain from Presentation” Refactoring.

Previous Posts:
Separate Domain from Presentation – part I
Separate Domain from Presentation – part II

Last time we explained how to refactor towards MVP – Supervising Controller pattern.
We left our project in the following state:

In this post I will complete the required refactoring steps and will suggest more steps to even deepen the separation of UI and BL concerns.

Refactoring Steps:

"Extract Interface" – in order to have a better encapsulation and separation of concerns, the CoursesPresenter shouldn’t access CoursesView directly. After all, the only functionality of interest to the CoursesPresenter is the CoursesView Courses property. Therefore, we will extract an interface from CoursesView class as follows: right click on the CoursesView class » Refactor » Extract Interface and select Courses property as shown in the figure below.

Compile the Solution and execute the Unit Tests.
In the CoursesPresenter class change all the occurrences of CoursesView to ICoursesView.
Compile the Solution and execute the Unit Tests.
Last time we indicated that the presenter should handle complicated user events by subscribing to the view. After introducing the ICoursesView interface it’s simple. Add to the interface the following code:

event Action LoadCourses;
event Action SaveCourses;

Implement the newly added events in the CoursesView class:

public event Action LoadCourses;
public event Action SaveCourses;

In the CoursesPresenter class rename the Load and Save methods to LoadCoursesEventHandler and SaveCoursesEventHandler respectively. Use right click » Refactor » Rename tool to rename it easily.
Wire-up the events in the CoursesPresenter constructor as follows:

public CoursesPresenter(ICoursesView view)
{
   this.view = view;
   view.LoadCourses += LoadCoursesEventHandler;
   view.SaveCourses += SaveCoursesEventHandler;
}

Compile the Solution and execute the Unit Tests.
In the CoursesView class add the notification code:

private void NotifyObservers(Delegate del)
{
    Delegate[] observers = del.GetInvocationList();
    foreach (Delegate observer in observers)
    {
        try
        {
            Action action = observer as Action;
            if (action != null)
            {
                action.DynamicInvoke();
            }
        }
        catch
        {
            // graceful degradation.
        }
    }     
}

Change the CoursesView.Load and CoursesView.Save methods to call NotifyObservers respectively:

private void FrmMain_Load(object sender, EventArgs e)
{
    //...
    NotifyObservers(LoadCourses);
    //...
}
private void Save()
{
    //...
    NotifyObservers(SaveCourses);
    //...
}

Compile the Solution and execute the Unit Tests.
Now it is the time to remove all the temporary instantiations of the CoursesPresenter class in the Load and Save methods. Remove all the occurrences.
In the Program.cs class instead of Application.Run(new CoursesView()) write the following:

static void Main()
{
   //...
   CoursesView coursesView = new CoursesView();
   CoursesPresenter coursesPresenter = new CoursesPresenter(coursesView);
   Application.Run(coursesView);
}

This concludes the “Separate Domain from Presentation” refactoring.
We ended with the following:

For next possible steps, consider the following:

Go over the CoursesView.Designer.cs and remove all the TableAdapter instances.
Create DAL and move Save and Load methods further more, from the presenter to the DAL.
Create the CoursesView and CoursesPresenter using Abstract Factory or using Dependency Injection.

Var{i-able;}

2009-05-28T16:47:00.006+03:00

Cross post from IRefactor

Here is a scoop; The good software engineer is lazy!
You don’t believe me? Then ask yourself this: If a good software engineer was not lazy why would he:

Automate processes?
Reuse a function instead of duplicating its code?
Explicitly name a function for its behavior instead of naming a function F1 and providing a non descriptive (and possibly long) documentation?

Yet, here is another scoop; The bad software engineer is lazy too!
While this statement clearly isn’t a shock to you, it immediately pop-ups the question:

What is the difference?

The difference is that a good software engineer is lazy in a constructive way (which allows to build reusable software and automated processes) while a bad software engineer is lazy in a destructive way (which destroys any chance for a reusable software and dooms you for long hours of struggling to understand and fix the bad code).

And here is a short example:
The var keyword allows implicitly typed variable declaration.
To tell the truth, it doesn’t allow to be a bad lazy software engineer!
Why bad? Take a look at the code below:

var database = DatabaseFactory.CreateDatabase();

What is the meaning (meaning = type) of the database object in this context? Do I really need to guess that? Does somebody expect me to go to its definition to find out?

//...
foreach(var observingStore in wareHouse.Stores)
{
 //...
}
//...

What is the meaning of the observingStore object in this context? Was it named observingStore due to its implementation of the Observer pattern (which implements IObserver), or is it just an object name of a Store, ObserverStore or even ArgicultureStore class type?

Remember, you want to be lazy in a constructive way; You want to read those lines of code without wondering. You want to immediately grasp the meaning (types) of the objects you are dealing with, without switching the context and jumping to a different location just to refresh your memory.

The var keyword was introduced for one and one purpose only; To allow usage of anonymous types. Therefore, this is the only place you should use it! Unless you are a bad lazy software engineer (which clearly is not the case :) ) you will follow the rule!

Separate Domain from Presentation – part II

2009-05-18T22:40:00.055+03:00

Cross post from IRefactor

This is a second post in the series of posts about “Separate Domain from Presentation” Refactoring.

Previous Posts:
Separate Domain from Presentation – part I

Last time we discussed the ways to disconnect the Presentation (FrmMain) from the Domain Object (CoursesDS) in the IRefactor.CoursesView project. As a consequence, instead of the bloated all-in-one initial project we ended with the following:

IRefactor.CoursesView – represents the View (CoursesView) without the domain object.
IRefactor.Common – represents the domain object (CoursesDS) without the UI elements.

It’s time to continue the UI and BL separations further more. For that purpose I will use the MVP pattern. It seems that there are a lot of misunderstandings regarding definitions of the UI/BL separation patterns (take a look here), I will focus on the following definitions:

In my post, MVP = Model-View-Presenter will basically stand for:

Model – Hey, I am the domain model;
I know how to manipulate model objects in order to perform required application logic and persistency.
I don’t know how to visualize to the user any information or how to respond to any action the user may take.
View – Hey, I am the view model;
I know how to visually represent to the user information (that will be provided for me by the Presenter).
I know how to perform simple data binding and possible simple UI actions that modify the visual layout of the screen.
I don’t know what to do when an application logic or persistency are required.
Presenter – Hey, I am the presenter model;
I know how to handle user requests to the View (which are more complicated than a simple data binding) and how to delegate those requests to the Model.
I know how to query the Model in order to delegate information to the View, if any should be displayed to the user.
I don’t know how to draw widgets graphically (that’s View’s concern) and I don’t know how to perform any application logic in order to derive that information (that’s Model’s concern).

Those who have sharp eyes, will probably spot here the use of a Supervising Controller (that doesn’t introduce right away drastic changes to the code in the spirit of Refactoring. Later on, one could turn the View into the Passive View while continuing to refactor).

Refactoring Steps:

Rename the IRefactor.CoursesView.FrmMain class to CoursesView. Go to FrmMain, right click on it and use Refactor » Rename command to rename it easily.
Create a class CoursesPresenter in IRefactor.CoursesView.

Add to CoursesPresenter class a pointer to the CoursesView (pay attention to the fact that the view is readonly)

public class CoursesPresenter
{
 private readonly CoursesView view;
}

Add to CoursesPresenter a constructor that receives CoursesView instance.

public CoursesPresenter(CoursesView view)
{
 this.view = view;
}

Compile the Solution and execute the Unit Tests.
Now we need to delegate user’s interactions from the view to the presenter. We can do it rather by inheriting the EventArgs and creating a CoursesEventArgs class, or we can let the CoursesPresenter query directly the CoursesView and grab the required data. Here I’ll grab the CoursesDS domain object directly. Add to the CoursesView the following:

public CoursesDS Courses
{
 get { return coursesDS; }
}

Let’s start with the Save event delegation. If you look closely at the coursesBindingNavigatorSaveItem_Click event handler, you will notice that the method has two different responsibilities. It treats the required data binding and then performs data access operation in order to save the CoursesDS domain object. To separate the concerns, let's use another Refactoring step called “Extract Method”. Select the data access code, right click on it and use Refactor » Extract Method command to extract the code into a new method called “Save”.

// ...
this.Validate();
this.bsCourses.EndEdit();
// Changed from auto generated code.
Save();
// ...

private void Save()
{
   if (coursesDS.HasChanges())
   {
       CoursesDS.CoursesDataTable changes =
           this.coursesDS.Courses.GetChanges() as
               CoursesDS.CoursesDataTable;
       if (changes != null)
       {
           taCourses.Update(changes);
       }
   }
}

Compile the Solution and execute the Unit Tests.
After breaking the coursesBindingNavigatorSaveItem_Click method we suddenly realize that the Save method doesn’t belong to the CoursesView class as it does a data access operation. By all means this operation should be inside the domain model (business logic). In the meanwhile we will push the method inside the presenter.
In CoursesPresenter create a new method called Save. The method will retrieve the CoursesDS domain object from the CoursesView and save the object into the DB.

public void Save()
{
   CoursesDS coursesDS = view.Courses;
   //...
}

Compile the Solution and execute the Unit Tests.
Copy all the code from the CoursesView.Save method into the CoursesPresenter.Save method and adjust the new code to its new “place” (pay attention to the CoursesTableAdapter that needs to be redefined).

public void Save()
{
    CoursesDS coursesDS = view.Courses;
    if (coursesDS.HasChanges())
    {
        CoursesDS.CoursesDataTable changes =
            coursesDS.Courses.GetChanges()
                as CoursesDS.CoursesDataTable;
        if (changes != null)
        {
           using (CoursesTableAdapter taCourses = new CoursesTableAdapter())
           {
               taCourses.Update(changes);
           }
        }
    }
}

Compile the Solution.
Now, for the fun part; Put all the code within the CoursesView.Save method inside remarks and declare CoursesPresenter object that calls to its Save method.

private void Save()
{
    //if (coursesDS.HasChanges())
    //{
    //    CoursesDS.CoursesDataTable changes =
    //        this.coursesDS.Courses.GetChanges()
    //            as CoursesDS.CoursesDataTable;
    //    if (changes != null)
    //    {
    //        taCourses.Update(changes);
    //    }
    //}
    CoursesPresenter presenter = new CoursesPresenter(this);
    presenter.Save();
}

Compile the Solution and execute the Unit Tests.
Walla! You have successfully moved a data access method from the view to the presenter. With continuous refactoring you can push that method even further in the data access layer.

A quick summary:

We introduced a new presenter class, called CoursesPresenter.
We moved the Save method (which does a data access operation) from the view into the presenter class. (Don’t worry we will eliminate the Save method from the CoursesView in the next post.)
The same should be applied to the Load method (FrmMain_Load). I won’t show it here, just use the same principle.

Here is the schematic view of the current IRefactor.CoursesView project.

Clearly, it’s not the same as the MVP pattern we depicted earlier. Future postings will explain additional steps to refactor towards the MVP pattern, by applying:

Events – the presenter handles complicated user events by subscribing to the view.
Interfaces – the presenter should manipulate the view only via an interface.Failing to do so, will break the view’s encapsulation.

References:
Take a look here for a good summary on Smart Client development.

Shooting without Aiming

2009-04-29T22:02:00.007+03:00

Cross post from IRefactor

During my lectures on “Refactoring & Design” I am frequently amazed to hear the following ideas:

“Doesn’t Design contradict Agile? Isn’t Agile about gaining speed, while Design about gaining bureaucracy?” - some ask.
“Why bother with Design? Eventually It’s impossible to do any design when using Agile methods, like TDD” - others continue.

I often compare the aforementioned questions to “Shooting without Aiming”. It won’t occur to shoot at a target without first aiming at it. The rule is true, especially when the time is short and every shot counts; You will spend an extra minute just to aim it well!

Shooting after Aiming is “life saving”!
So, How does it even come to any mind to code without thinking(thinking=Design)?

Please, don’t take my word on it. See what Robert C. Martin has to say about The Scatology of Agile Architecture. Robert C. Martin knows a thing or two about Agile Development. After all, he was the originator of the meeting that led up to The Agile Manifesto.

Dude, I blew up the Demo!

2009-04-24T16:09:00.008+03:00

Cross post from IRefactor

I am sure, we are ALL familiar with the situation:

Morning… The sun is shining, the birds are chirping… You are sitting in front of your computer, sipping a delicious cup of coffee. Then, in the corner of your eye, you spot movement; your VP Marketing approaches you with a big smile on his face:

“Jonathan”, he says, “Just got important news, we have a big opportunity! We have been requested to demonstrate our super complex web analysis capabilities to a huge potential client. Could we build a quick demo?”

You sigh and start coding…

You don't sleep neither eat; you copy and paste; you code; you build and execute and after stressful (but, yes, enjoyable) five days you provide a top-notch Demo.

The new “toy” becomes the hottest news in the office.
It’s cool, it's fast, it's colorful and it demonstrates an innovative functionality and thinking!

The VP Marketing is in heaven; he presents the demo to the client and gets an enthusiastic response.

“Jonathan”, his eyes are gleaming, “They are excited! They just need a small feature - export to excel, to evaluate it a little bit more.”

You return to the operating table and add some “quick & dirty” code to export the analysis to excel.

“Jonathan”, your VP Marketing, “Great work! Could you also add a small feature of notification by email?”

A few days later…

“Jonathan, Well done!, Could you also add…”

A year later, you find yourself maintaining the demo and cursing that cheerful morning you had agreed to develop the goddamned application!

If you ask your VP Marketing what happened, he will honestly say: “Dude, I blew up the demo!” Remember the Honey, I blew up the kid!? Your VP Marketing, "accidentally", blew up your five days old “child” into a giant “monster”.

It’s common for a small-mid size companies to turn their “demo” applications into production ones. The “time to market” is crucial; once the demo was introduced successfully, the features are added patches over patches resulting in a House of Cards AntiPattern.

House of Cards AntiPattern – a continuous patch (card) over patch (card) which is done in order to correct a bug or to add a focused feature without design or refactoring considerations.

Even in a small demo application, there is a place for a careful examination of the developed features. You can make assumptions; you can speed-up the UI development, but you need to design the core features, as you develop the production code:

Separate the Domain from the Presentation, using MVP pattern for example.
Use Façades to shadow the BL.
Provide a well organized BL. (Don’t try to address all the future possibilities and requirements. Just provide good object oriented basis).
Don’t duplicate code, don’t provide lengthy and hard to read methods.
Provide Unit Tests and test the BL as much as possible.
Deal with “considerable”exceptional situations (It’s OK to decide not to deal with uncommon demo scenarios).

Notice, it is perfectly fine to make assumptions and to apply some limitations during the demo development. However, building the demo correctly will ease the move to the production, even if a certain feature is redesigned or redeveloped.
Undoubtedly, it will ease the development of any additional “demo” features for more potential clients.

As for the managers, try to remember; unless you want to make excuses for unmaintainable and hard to change code, you need to allow your development teams to work a little bit longer, just to produce a better demo!

Separate Domain from Presentation – Part I

2009-04-18T16:51:00.022+03:00

Cross post from IRefactor

Visual Studio can be a swiss knife in the hands of a Software Developer.

You want a fully functional application within several hours; here you go sir:

Create Windows Forms Application.
Add relevant Data Sources (in Figure 1 below: Courses table).
Drag generated entities from the Data Sources onto relevant Forms.
Add minimum code to show the Forms in the required order.
Compile & execute.

Walla, I present you an “enterprise application”!
Though it looks amateur, it allows fully functional CRUD operations.

Figure 1

But, the power can corrupt…

Lately, I came across a few projects implemented using the above approach. Needless to say, the projects were “spaghetti code” - all the UI elements, visual states, business logic & data access, were centralized within a few Forms.

(Don't think it's a rare situation! There are enough companies that try to "save" time using such a “quick & dirty” approach).

I am a pragmatic Software Engineer and I do believe that the “quick & dirty” approach is vital in some cases.
If you present a demo application that demonstrates your capabilities; go ahead, use the necessary tools to implement it as fast as possible.

However, if you develop a real life applications using the above approach it’s a sure road to hell. Slowly but surely the “fast development” takes more and more time:

The customer’s button event click is very similar to the employee’s event click, but correlate and update different UI elements » you duplicate the logic in both places.
New requirement add new conditions to some wizard flow » you add an “if” statement to address the conditions. Sometimes you add a “switch” statement due to the fact that many “ifs” already exist.
New requirements impose saving more data » you add more parameters to your methods. You also go further and add those parameters to each and every place (form/method) where the change is required.
The classes and methods become huge, they are overcrowded with UI elements, visual states transformations and business logic. Next time you try to read the code, you will need at least a few hours to concentrate and walk through the mess.

The Project Manager responsible for the aforementioned projects, said to me:

“Any change request I want to apply, come back with unrealistic time estimations. When I ask the developer why it takes so long, he answers: My Gosh – do you know what it takes to change that code? Do you understand how long I need to retest the application, just to verify I didn’t break anything?”

It seems obvious that if in the first place, the project had been written in clear separation of UI, Business Logic and Data Access Layers, it would have been easier to maintain the product lifetime. However, clearly it is not the case here, so what can we do?

One of the tools we can apply here is: Refactoring.

Refactoring is a process of improving software’s internal structure without changing its external behavior. Refactoring ensures completeness of the external behavior, by executing automatic unit tests. We improve the code in incremental small steps (refactoring steps) and each change is followed by a compilation and unit tests execution.

In the following posts I will demonstrate refactoring called “Separate Domain from Presentation”, which obviously breaks the tight coupling between UI and BL. After finishing the demonstrations of the refactoring process itself (it will take me several posts to do it) I will also explain how to create the suite of unit tests, which allow validation of external behavior completeness.

Remarks:

I will refactor the application from figure 1 (above).
The application contains one View (FrmMain) and one domain object (CoursesDS).
Though the sample application contains one Form and one DataSet, the same technique can be applied in more complicated situations. Just identify the groups of objects that fit together and apply for each one of them the following steps of separation.
It’s advisable to download the sample IRefactor.CoursesView project and go through the refactoring steps while reviewing the code.
In the next posts I will introduce how to enhance the separation using refactoring towards MVP (or MVC) patterns.
It’s harder to write about the refactoring process, than actually implement it. Don’t be intimidated, it takes longer to explain each and every small step (and provide screenshots) than to do it in practice. To Separate Domain from Presentation (up to MVP) takes me about 10 min of work.

Refactoring steps:

When the Irefactor.CoursesView project was defined initially, Visual Studio generated a DataSet called CoursesDS for the Courses Data Source. As you can see, the Irefactor.CoursesView project mixes UI (FrmMain) elements and Domain (CoursesDS) elements.

Figure 2

Let’s start by removing the CoursesDS domain object from the UI (View).
Create a project IRefactor.Common and copy there CoursesDS DataSet.
(Drag the CoursesDS from project to project, Visual Studio will do the rest).

Due to the fact that CoursesDS is a VS auto generated class, one should also copy the connection string definition which is stored in the Settings of the IRefactor.CoursesView project. Add Settings.settings to IRefactor.Common Properties folder and copy the connection string.

Figure 3

Compile the Solution and execute the Unit Tests.
Change the FrmMain (View) to use the newly created IRefactor.Common.CoursesDS DataSet.
Open the FrmMain’s designer. Remove the coursesDS (the instance of the domain object: IRefactor.CoursesView.CoursesDS DataSet – see red arrow 1).

Figure 4

On the Toolbox window, under the recently added IRefactor.Common Components you will see the IRefactor.Common.CoursesDS DataSet.
Drag this CoursesDS to the FrmMain Form.

Figure 5

Dragging the IRefactor.Common.CoursesDS DataSet onto the FrmMain surface generates an instance of the class. Rename it to coursesDS (to match the previous name).
Repeat the three last steps also for IRefactor.CoursesView.CoursesTableAdapter (see Figure 4, red arrow 2)
Select the BindingSource (see Figure 4, bsCourses) and change its DataSource to coursesDS instance (coursesDS now comes from IRefactor.Common project). Also change its DataMember to point the Courses table.

Figure 6

In FrmMain code behind file add reference to the IRefactor.Common namespace and change the CoursesDS to a fully qualified name.

// add reference

using IRefactor.Common;



// ...



private void coursesBindingNavigatorSaveItem_Click

{

(object sender, EventArgs e)

  // ...



  // change the coursesDS to IRefactor.Common.CoursesDS

  IRefactor.Common.CoursesDS.CoursesDataTable changes =

        this.coursesDS.Courses.GetChanges()

            as IRefactor.Common.CoursesDS.CoursesDataTable;

  // ...

}

Compile the Solution and execute the Unit Tests.
Go over IRefactor.CoursesView and remove all instances of the previous domain object IRefactor.CoursesView.CoursesDS DataSet. Also, delete the CoursesDS.xsd file from the project.
Compile the Solution and execute the Unit Tests.

We have successfully completed the first steps. We have separated the UI project called IRefactor.CoursesView from the Domain Project called IRefactor.Common. Now it’s time to become serious and continue the refactoring towards the MVP pattern.

The Hunt for a Software Engineer

2009-04-18T00:30:00.003+03:00

Cross post from IRefactor

This week I had interesting discussions regarding hiring and interviewing professional personnel.

The reason it was so interesting, is the fact that the discussions were raised simultaneously by two friends of mine, each from his unique point of view.

David is a R&D Manager who leads successfully a complicated software project written in .NET technologies.

David tries to hire a Software Engineer with specific experience in Smart Clients and Complicated Servers applications but without any success.

David complaints that most of the candidates he meets have a superficial knowledge and don’t meet his expectations.

Daniel is a talented Software Engineer whose major experience is in ASP.NET, willing to change his place of work. Daniel is a very dedicated person; he attends almost each and every summit he can on .NET technologies. He also reads quite a lot of blogs and articles in order to enhance his knowledge.

Daniel had already attended more than dozen interviews, most of which he failed because he was unable to solve some “tricky” (according to his words) questions.

By “tricky”, he gives an example of: “Given a uniformly distributed function between 0 to 1 write a function that generates unique numbers from 1 to N in complexity of O(…) and …” and that’s there he loses his nerve.

“What the hack”, he says to me, “The company even doesn’t deal with any statistical or mathematical computations, all it does is pretty standard enterprise application; retrieve, show and update”.

On the one hand it is ridiculous that Daniel cannot pass interviews, but on the other hand it is also true that we lack good Software Engineers.

But wait, could it be that the problem is within our industry (or us)?

· Understanding that there is a need to hire a new Software Engineer mostly comes too late (in the project’s schedule).

· As a consequence, due to time constraints, there is no time to train the new employee. Therefore the employee must meet very rigorous requirements.

· In order to ensure those requirements (that vary a lot from company to company, based on their line of business), the interviewer tries to infer candidate’s competence using one of the following tools:

o Ask domain specific question, based on the interviewer’s (or his company) experience or immediate needs.

o Ask “quiz” questions, question that can be solved using some tweaking.

The interviewer forgets Peopleware which clarifies: “Major problems of our work are not so much technological as sociological in nature.” Failing to answer a tweaking (“a-ha”) question isn’t a virtue you would like to judge on.

· Finally, candidates that somehow meet the requirements are being hired, which deepens and narrows their experience in the long running term.

A good candidate doesn’t need to know how to tweak a domain specific problem within an hour. Moreover, a good candidate doesn’t need to be a specialist in Smart Clients applications.

Don’t get me wrong, if such a candidate appears during the interviewing process I will gladly hire him (if I need such a skill for long term).

However, if your projects and recourses are planed correctly, you can loosen your requirements a bit.

I have always believed that a Software Engineer should be as versatile as possible and therefore the minimum bare requirement I seek is a very strong software engineering background.

In my opinion, a Software Engineer must understand in different “tools of trade”. He needs to know why it is better to apply this pattern or that pattern, when it is suitable to use Smart Client applications and when it is not, how to build good infrastructure and clean software and etc… etc…

Having good software engineering skills, doesn’t mean you don’t need to specialize vertically in a specific field. With the correct mentoring and coaching, candidate’s experience in several disciplines he chooses, will evolve with years (and this can be a whole another post) and I even expect it to happen.

And that’s how, my conversations with David and Daniel this week ended by discussing how do I find this bare minimum in the candidates, using technology questions and without any tricky (“a-ha”) approaches (of course there are also non technology question that I ask during the interview in order to review candidate’s soft skills).

Here are the virtues that I try to pursue during an interview:

· A candidate must show a strong understanding of Software Engineering principles

· A candidate must be able to learn and evolve with the time.

· A candidate must have a passion for the trade.

The last virtue is extremely important; how many people do you know that work in the hi-tech industry, just because it seems to be “a shiny, nice place”? You probably met such people in the past when they complained to you not to discuss any work issues during the lunch time.

And here is the basic skeleton of the interview:

Previous Experience

I ask the candidate to choose an example from his previous work and to explain its design.

I expect the following:

· Problem explanation – clear and concise explanation of the domain problem.

· Solution explanation – short conceptual model or class diagram explaining the solution, including alternatives that were considered, technological pitfalls that were overcome and etc…

It’s amazing to see that many candidates don’t know how to communicate simple technological problems, don’t know what they really tried to solve in the first place and why the solution was chosen the way it was.

Design

I ask a design question from a well known domain.

A well known domain helps to remove obstacles when introducing to the candidate some domain specific logic that might come from the interviewer company’s experience.

An example of such a question will be:

“Please design the MSN Messenger” or “Please design the Linkedin service”

During the interview I add more and more constraints to the question.

I also provide some leads that may (or not) help to solve the question.

I expect the following:

· An ability to adjust the design with each added constraint.

· An ability to learn from my leads and to change the solutions accordingly.

Technology Questions

No tricks here, no “a-ha” questions\answers.

I really don’t want the candidate to go back home following an interview with me and suddenly to have the “a-ha” answer for the question I asked.

I just try to reveal how deep the candidate understands the “tools of trade” (based on his experience).

Here are a few examples:

· What is the difference between class and struct?

The question yields in 70% (there are still people that don’t know the difference?) a correct answer that a class is a reference type sitting on the heap and a struct is a value type sitting on the stack.

But, wait, what does it really mean?

How that helps you to build better software in .NET technologies?

(Here is a quick hint: in .NET everything is a struct or a class. Basic int is a struct; why is that?)

· What is the difference between a thread and a process?

The question drives a broad discussion over why and when we need threads, what are the synchronization methods available in .NET framework, what are their pros and cons and etc…

· How do you retrieve a record from a Database?

This question also drives a broad discussion about connected and disconnected modes, dataset\datatable, typed dataset\datatable, XML, ORM, optimistic and pessimistic locks and etc…

By adding more and more constraints on the questions asked I evaluate how deeply the candidate knows his “tools of trade”. He doesn’t need to know all the answers, but you will see; a passionate Software Engineer will know quite a few things under the hood and even if he won’t know, he will try to figure it out, discussing with you all the possibilities and alternatives.