Saturday, November 20, 2010

Fifth Meeting of the "Software Craftsmanship in Israel" Group

Our 5th meet-up is rolling out (on 15.12.2010) and I am very excited as this time there are plenty of surprises :)
First, we have a lot of cool giveaways to give during the meet-up (A hint is here).
Second, the meet-up's title is: All you need is… Codeand its format is slightly different: 

We are going to discuss different SW principles: DRY, TDD, Code Reviews and etc...
The demonstrations will be done in 3-4 different groups. Each group will discuss a different SW principle.
Each 30 min
, after sounding some music the participants will exchange their groups.

Each principle will be demonstrated either by doing pair programming/kata or by a code demonstration.

We are going to cover the following topics*:

1. DRY 
2. TDD
3. Code Reviews in Practice
4. TBD (still under discussion)

Remarks:

* Please bring your laptops (with the environments set-up) to the meeting.
** Code Reviews group  will provide an option to review YOUR code...

Together we will review participants' code, identify code smells and provide solutions for cleaner and better implementation...

Please don't hesitate to bring your code base with you
...

 Time frames:

18:00 - 18:25 - Gathering / Mingling
18:25 - 18:30 - Short Intro / Explaining the meeting's set-up 
18:30 - 19:35 - Round I (30min + 5min break + 30min)
19:35 – 19:45 - Break + Giveaways
19:45 – 20:50 - Round II (30 min + 5 min break + 30min)
20:50 – 21:00 - Wrap-up + Giveaway 

Giveaways:

We have great giveaways to give during the meeting. DON'T miss them :)

Food:

Though, we are plaining to provide food - you are more than welcome to bring more food for the benefit of all (user generated food).
The meeting will take place here.
Please register here.

Tuesday, November 9, 2010

Mentorship - The First Impression

On our 4th Software Craftsmanship meet-up I have introduced the Mentorship / Apprenticeship program.

Since then, I have received 2 great apprentices to mentor.

MentorshipApprenticeship - Pairing

In the following series of posts I would like to summarize our mutual experiences (questions, debates and learning processes) for the benefit of the community.

During the first meeting we discussed the following topics:

Introduction:

We talked about each others experience: what we learned from that experience and what we didn't :) [A hint: We all learned that we want to become software craftsmen :)]

What does Software Craftsmanship stand for?

I reviewed the basic Software Craftsmanship ideals and values and we discussed their impacts on our professional lives. [An example for such a value is: Deliberate Practice]

What are the objectives of the Mentorship program?

Each apprentice prepared a list of his objectives and after a short review, we discussed how to meet them. [An example for an objective is: Enhance Unit Test Knowledge]

Paradigms and Principles:

I prepared a list of paradigms and principles that each apprentice should learn. We reviewed the list and the reasons why those paradigms/principles are important. [Some examples of the principles: Refactoring or OO Design Principles]

Information Exchange:

We exchanged our RSS feeds in order to enrich our learning sources.

Misc:

We discussed miscellaneous issues that varied from development, career paths and social media. [For example, we discussed whether a software engineer should have a blog and if yes, then what to post about]

All in all those were very nice first meetings... Now we are looking forward to sink our teeth into some Object Oriented Principles/Code Smells and Unit Tests. Each apprentice will review (on his own time) an open source project which we will analise together later on, in order to demonstrate and learn the principles.

Friday, November 5, 2010

I am guest of Microsoft at Tech-Ed 2010 Eilat

I was announced that I was selected to be a guest of Micorosft at Tech-Ed 2010 (Eilat) as 1 of the 10 bloggers of the community.
Cool!!!
Thanks a lot guys :)!!!
 Teched.Israel.Blogger.UriLavi

Software Craftsmanship - Meeting 4


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:

Tuesday, October 19, 2010

Mentorship Apprenticeship Program

In the previous post I wrote that as part of our next Software Craftsmanship meetup I will establish and start the enrollment process for a Mentorship Apprenticeship Program.

Since then I received quite a few emails and questions regarding the program and decided to summarize the answers in a Q&A form.

What does the Mentorship (Apprenticeship) program stand for?
How does the Mentorship (Apprenticeship) program work?
How a Mentee finds/chooses a Mentor?
What is the Mentor's responsibility?
What is the Mentee's responsibility?
What is the minimum period of the Mentorship (Apprenticeship) Program?
Can a MenteeMentor leave in the middle of the Mentorship (Apprenticeship) program?
What happens at the end of the Mentorship (Apprenticeship) program?
Can a Mentee and a Mentor to be from different companies?
Should a Mentee and a Mentor have the same technological background?

Q: What does the Mentorship (Apprenticeship) program stand for?

A: We all find ourselves looking for a Mentor to guide us throughout our work. Software Development is a hard profession to master and having a Mentor who can teach us, review our decisions (code, design, architecture) and throw light on different technological/management matters will no doubt enhance our knowledge, skills and capabilities. Moreover, it is my strong belief that such a program will be of benefit to the software development community as a whole.

Q: How does the Mentorship (Apprenticeship) program work?

A: A Mentee will select a Mentor who should accept the mentee as his apprentice, and the mentor will act as his guide for a minimal Mentorship (Apprenticeship) period.

Q: How a Mentee finds/chooses a Mentor?

A: As a part of our Software Craftsmanship in Israel Community, I will maintain a list of Mentors. The list will be constructed primarily based on the community feedback. A Mentee will approach a Mentor from the list based on the community feedbacks and his best impressions from the Mentor's capabilities, publications and etc... Should the Mentor be available, both the Mentee and the Mentor will commit to each other for at least a minimal mentorship (apprenticeship) period.

Q: What is the Mentor's responsibility?

A: A Mentor will:
  • Provide Technical Guidance and Feedback.
  • Provide Reading Sources.
  • Review and Build Career Paths.
  • Hold Code Reads, Code Reviews and Pair Programming.
  • Conduct Architecture and Design Reviews.
  • Review Management Decisions and Advise Management Dilemmas
  • Anything else that will be agreed between the Mentor and the Mentee.
  • Provide feedback to the community.

Q: What is the Mentee's responsibility?

A: A Mentee will:
  • Learn, Learn, Learn.
  • Provide feedback to the community.

Q: What is the minimum period of a Mentorship (Apprenticeship) Program?

A: Four (4) months. Each Mentee and Mentor may together decide at the end of the period whether they wish to extend the period which, in my opinion, should be longer.

Q: Can a MenteeMentor leave in the middle of the Mentorship (Apprenticeship) program?

A: The whole purpose of the mentorship (apprenticeship) program is the commitment that both the Mentee and the Mentor make towards each other. If you cannot commit, I suggest you do not enroll in the program. I suppose that there will be exceptions, but those will be exceptions to the rule.

Q: What happens at the end of the Mentorship (Apprenticeship) program?

A: At the end of the mentorship (apprenticeship) program a Mentee can choose another Mentor. Eventually (after being in several mentorship programs) a Mentee will be ready to become a Mentor himself.

Q: Can a Mentee and a Mentor to be from different companies?

A: In my opinion, not only is that possible, but also advisable.

Consider, what is there to gain:
  • Other techniques, technologies and approaches.
  • An objective view that teaches and directs, without any fixations on the solutions and approaches being applied within your company.

But, what about intellectual property (IP), will you ask?

At least from my point of view (and I have seen quite a lot of solutions from different companies), most of the issues, ideas and code aren't original, nor patentable. The architectures and the designs are pretty much the same, the issues and even the implementations are often identical and most of them are very well known and in the public domain. Companies like Facebook, eBay, Twitter and etc... freely talk about their architectural decisions and implementations; So, why we should we be different?

Nevertheless, there might be some unique business rules or algorithmic ideas being employed by a company and in such a case, please don't discuss those. Use your best judgment and if in a doubt, refrain from any discussion of those points. There will be still plenty of issues to deal with.

Q: Should a Mentee and a Mentor have the same technological background?

A: Not necessarily. It totally depends on the Mentorship (Apprenticeship) program's intention. If a Mentee wants to learn a different stack of technologies - then that might make sense. But if a Mentee wants to increase his knowledge of the current stack, it makes sense to approach a Mentor with the same technological background.

Monday, October 4, 2010

Software Craftsmanship Podcast



Here you can find a short podcast I recorded with Ran & Eran from Reversim; The subject is Software Craftsmanship in Israel Group (in hebrew).

(mp3 is here.) 

Many thanks to Ran, Eran & Ori !!!

Fourth Meeting of the "Software Craftsmanship in Israel" Group

On 18.10.10 at 18:30 we will conduct our fourth Software Craftsmanship meeting.

The agenda is:


Introduction:

  • Introducing Mentorship / Apprenticeship Program.

I (~40 - ~60 min) - Lectures: 

Each lecture will be up to 20 min.

Depending on the time, we will have 2-3 lectures.

  • Structure 101

  • Effective Code Reviews - How?

  • "Legacy" Code & Unit Tests

II (~80 min) - Coding Dojo:


  • Demonstrating Pair Programming (Randori Style). We will write a small program, evolving its design and tests.

If you have a laptop with your environments set-up, please bring it to the meeting.

Please register on LinkedIn event or on Eventbrite event (next time only Eventbrite :) ).

The meeting will take place here.

Saturday, October 2, 2010

The Importance of Mentorship

(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.

Thursday, September 30, 2010

Effective Code Review - A Presentation

(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.

Tuesday, September 28, 2010

A Round Table

(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!

Monday, September 27, 2010

Software Craftsmanship - Meeting 3

Our 3-id Software Craftsmanship meetup was as usual divided into 2 parts.

During the first part - Lior Friedman gave us an interesting lecture on Context Based Design, DRY, KISS and SOLID.

Lior also demonstrated how to take a legacy code and apply unit tests on it.

Below you can find the lecture:



During the second part - we had a Coding Dojo.

Some of us implemented the Lychrel Numbers Detector (in Java, JavaScript and C#), while others continued with Lior's example and introduced unit tests in order to refactor the code.

My special thanks to Tzipi and CheckPoint for providing the space.

Monday, August 16, 2010

Short Roman Numeral Kata

(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.

Sunday, August 8, 2010

Third Meeting of the "Software Craftsmanship in Israel" Group

On 15.09.10 at 18:00 we will conduct our third Software Craftsmanship meeting.

The agenda is:

Writing Clean Code:
Topics (60-80min):

  • Applying Unit Tests on Existing Code

  • Refactoring

Hands-On part (40m-60m):

  • Applying Unit Tests on Existing Code

  • Coding Dojo

I highly reccomend the session; If you want to understand what is the process of applying Unit Tests on "Legacy Code" (Existing Code) then you should come.

If you have a laptop with your environments set-up, please bring it to the meeting.

Please register here.

The meeting will take place here.

(Pay attention, this time the meeting will take place in Check Point's offices in Tel Aviv)

Sunday, July 25, 2010

Who Cares? (Software Craftsmanship - Meeting 2)

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.




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