Uri Lavi : Peopleware

Management Tips - A Hebrew Podcast on Management and Leadership

Uri Lavi — Tue, 03 Jul 2012 01:02:02 GMT

As promised, today we (Lior Cohen and I) have announced our new podcast in Hebrew on Management and Leadership.

In this podcast we will try to provide tips, tools and best practices from our experience as well as from the experience of other prominent leaders in the Israeli work space. I believe there are many tales about managers and management. Without going into too much details, we believe that management is a skill you need to grow slowly and gradually (the same way as you grow your technology skills for example). It is a long way to go... A well skilled manager works hard every day to "clean" the way for his team members in order to allow THEM to do what they know best (like delivering software for example).

My hope that this podcast will help everybody, who wants to learn and to grow these skills.
My personal believe is that this podcast isn't only for managers.
Since one of the keys of good management is creating a highly gelled and efficient environment - I hope that others will contribute (and listen) as well.

I will be happy to hear you feedbacks (or questions or management dilemmas).

You can find the podcast here: www.mngttips.com.

Giving a talk on Fostering Software Craftsmanship (Building Successful Teams)

Uri Lavi — Thu, 03 May 2012 12:10:00 GMT

I will be giving a talk on Fostering Software Craftsmanship (Building Successful Teams) on May the 7th at the Hub Tel - Aviv.

During the last years I've been asked several times on the topics of the talk. Since the session is usually about an hour and so, needless to say that I am only scratching the surface. There is definitely more into that. I only provoke initial thoughts on our profession both from a personal and a team view perspectives.

I will be more than pleaced if you continue to be in touch, reaching for questions, suggestions or taking more personal involvement in the Software Craftsmanship community (here and here)

In addition, in the following days I will announce a new podcast that I intend to record.

This podcast will be connected to some topics I am mentioning in the talk, but obviously will deal with more broader issues and more deeply.
I'll post the details soon!

What should I learn in my CS degree?

Uri Lavi — Fri, 25 Feb 2011 19:40:15 GMT

My strongest believe is that everyone who devotes his life to Software Engineering, should have a CS degree.

Why? Well, it's a different question, so I would postpone my answer for now.
Instead, in the following post I would like to emphasize the subjects (and hence the tools) one should acquire during his studies.

These tools are essential in creating a "shared" language between us the engineers.
These tools are essential in being the solid ground of our day to day architectural and lingual abstractions.
These tools are essential in being the means of our research capabilities, logical deduction, advantages and disadvantages of each method we apply and etc...

In my opinion, those are the topics one should concentrate on:

Data Structures - Any course that involves Data Structures, from basic to more complex Data Structures.
Algorithms - Graph Algorithms, Dynamic Algorithms, Greeding Algorithms, Aproximate Algorithms, Computational Geometry and etc...
Operating Systems - Everything that involves Operating Systems from theory to practice. If there is a lab on OS, take it!
The importance of understanding the bits and bytes of the biggest abstraction we work against every day is priceless.
Artifical Intelligence - Searching techniques, Logic deduction, Decision tees, Learning technique such as Markov Chains, Neural Networks, Bayesian Networks and etc...
Programming Languages - No, it isn't "Programming in Java"; These courses involve the principles of Software Languages, which are crucial for identifying the right tools for the job.
Imperative and Declarative Languages; OOP, AOP, Functional and Logical Languages; The more principles you learn (and the more languages you see) the more you will understand how to apply these languages and when.

In addition, I recommend taking a few "narrowing" courses, courses that are deepening your expertise in a specific field.
Some examples are: Natural Language Processing, Computer Vision or Distribute Programming.

It's worth noting that, in my opinion, practical principles of "constructing" software should be learned differently.
Those skills are better acquired by enrolling into an apprenticeship program, by reading classical books and essays, by rubbing elbows with others or by deliberately practicing.

If you are interested in such practical experience, please apply for the Mentorship/Apprenticeship program we enrolled in our Software Craftsmanship Group.

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

Uri Lavi — Thu, 06 Jan 2011 01:54:55 GMT

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.

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 rigor Code 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.

Software Craftsmanship - Meeting 4

Uri Lavi — Fri, 05 Nov 2010 13:25:00 GMT

Boy, I had so much fun during our 4th meeting...

There were more than 80 people, deeply concerned about our profession and eager to learn best patterns & practices.
In the first part we had 3 lectures: Code Reviews (Tools & Processes) - Ran Tavory , Structure 101 - Eran Harel and Legacy Code & Unit Tests - Uri Lavi.
In the second part Aviv Ben-Yosef & Yoni Tsafir demonstrated pair programming (Randori Style) while solving the Bowling Kata exercise.

Watching this great audience was very satisfying and I received a lot of positive feedback, that will also improve our next sessions.

During the meeting I have also introduced the Mentorship/Apprenticeship program.
Today, a few weeks after the meeting, I can proudly say that I mentor two great apprentices.
Though we only started the process, I expect that the mentorship program will bring the change to our community and will create more professionals and software craftsmen.

Below you can find the lectures and the source code of the Kata:

The Bowling Kata source code in Java.
The Game class:

The Game tests:

The Importance of Mentorship

Uri Lavi — Sat, 02 Oct 2010 23:13:00 GMT

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.

A Round Table

Uri Lavi — Tue, 28 Sep 2010 02:28:43 GMT

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!

Who Cares? (Software Craftsmanship - Meeting 2)

Uri Lavi — Mon, 26 Jul 2010 00:15:19 GMT

I dare to say WE DO... WE CARE !!!
This Wednesday (on 21.07.2010) we had a second Software Craftsmanship meeting.

More than 50 "hungry" software craftsmen came to share their knowledge and practice their software skills.
We reviewed bad code, identified Code Smells and suggested how to improve it.

It is well known that the best way to communicate between Software Professionals is to write and read code together. Therefore we WROTE code in Dojo Style.

I am really excited to see such a community that truly cares about its craft.

If you thought there are none like you, think again...
It doesn't make any difference what type of technology you are using; There are solid Software Principles that are universal and a technology is just one of the tools you should know how to apply.
It's really up to us...

If you are for clean, maintainable and readable code, professionalism (craftsmanship over crap, [also here]) and thorough knowledge, then your place is with us.
Join our group, come to our sessions (every ~1.5 months), share your knowledge and resharpen your skills.

Here are the slides from the meeting.

Software Craftsmanship - 2nd Meeting

In addition, you can also find below, my suggestion to the Roman Numeral exercise we did.
(Actually, I can refactor the solution even further, but in the real world scenario I think such a solution will be an overkill).

public class ShortRomanNumeral

{

    internal struct RomanMapper

    {

        public int Value { get; set; }

        public string Presentation { get; set; }

    }

    private const int MinShortRomanValue = 0;

    private const int MaxShortRomanValue = 3999;

    private const string zeroRomanPresentation = "Nulla";

    private readonly RomanMapper[] shortRomanMappers = 

    {

        new RomanMapper(){Value = 1000,  Presentation = "M"},

        new RomanMapper()Value = 900,   Presentation = "CM"},

        new RomanMapper(){Value = 500,   Presentation = "D"},

        new RomanMapper(){Value = 400,   Presentation = "CD"},

        new RomanMapper(){Value = 100,   Presentation = "C"},

        new RomanMapper(){Value = 90,    Presentation = "XC"},

        new RomanMapper(){Value = 50,    Presentation = "L"},

        new RomanMapper(){Value = 40,    Presentation = "XL"},

        new RomanMapper(){Value = 10,    Presentation = "X"},

        new RomanMapper(){Value = 9,     Presentation = "IX"},

        new RomanMapper(){Value = 5,     Presentation = "V"},

        new RomanMapper()Value = 4,     Presentation = "IV"},

        new RomanMapper(){Value = 1,     Presentation = "I"}

    };

    private readonly int value;

    private readonly string presentation;

    public ShortRomanNumeral(int value)

    {

        if (value < MinShortRomanValue || value > MaxShortRomanValue)

        {

            throw new ArgumentException();

        }

        else

        {

            this.value = value;

            presentation = CalculateRomanPresentation();

        }

    }

    private string CalculateRomanPresentation()

    {

        if (value > 0)

        {

            return NonZeroRomanPresentation();

        }

        return zeroRomanPresentation;

    }

    private string NonZeroRomanPresentation()

    {

        int currentValue = value;

        StringBuilder presentation = new StringBuilder();

        foreach (RomanMapper romanMapper in shortRomanMappers)

        {

            while (currentValue - romanMapper.Value >= 0)

            {

                currentValue -= romanMapper.Value;

                presentation.Append(romanMapper.Presentation);

            }

        }

       return presentation.ToString();

    }

    public override string ToString()

    {

        return presentation;

    }

}

And here are the Unit Tests:

[TestCase(0, "Nulla")]

[TestCase(1, "I")]

[TestCase(2, "II")]

[TestCase(3, "III")]

[TestCase(4, "IV")]

[TestCase(5, "V")]

[TestCase(6, "VI")]

[TestCase(8, "VIII")]

[TestCase(9, "IX")]

[TestCase(10, "X")]

[TestCase(17, "XVII")]

[TestCase(23, "XXIII")]

[TestCase(47, "XLVII")]

[TestCase(89, "LXXXIX")]

[TestCase(3999, "MMMCMXCIX")]

public void ToString_OfANumber_ReturnsRomanPresentation(int number, string romanPresentation)

{

    Assert.AreEqual(romanPresentation, new ShortRomanNumeral(number).ToString());

}

[TestCase(-1)]

[TestCase(-2)]

[ExpectedException(typeof(ArgumentException))]

public void ToString_OfANegativeNumber_ThrowsArgumentException(int number)

{

    new ShortRomanNumeral(number);

}

[TestCase(4000)]

[TestCase(5000)]

[ExpectedException(typeof(ArgumentException))]

public void ToString_OfANumberGreaterThan3999_ThrowsArgumentException(int number)

{

    new ShortRomanNumeral(number);

}

How will you find your next job?

Uri Lavi — Sun, 20 Dec 2009 00:39:14 GMT

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.

A Cult Programmer

Uri Lavi — Fri, 12 Jun 2009 22:01:00 GMT

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.

Var{i-able;}

Uri Lavi — Thu, 28 May 2009 20:48:00 GMT

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!

Dude, I blew up the Demo!

Uri Lavi — Fri, 24 Apr 2009 19:52:00 GMT

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!

The Hunt for a Software Engineer

Uri Lavi — Mon, 13 Apr 2009 03:25:00 GMT

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.