The First Rule to Software Craftsmanship

Eli Lopian    .NET Tests    

There has been a lot of noise about software craftsmanship.

I think it’s great that people are talking about how software development should become a true craft.

So where’s the catch? Communication as usual.

When I look at what the developer groups talk about online…they discuss design. But I have seen many good developer discuss (read: rant) about how no one listens to them, no one knows how to do things right, the result will not work, the design is not good enough…and so on. That kind of “talk” simply does not lead to craftsmanship.

Sitting in the aisles and ranting about how things won’t work, is probably the least efficient way to finding out what does. The first step towards true craftsmanship is to ask “How can we make this work?”, “How can I help make it work” and not “Why my way is better” or “How this will fail” You will be able to do wonders when you look for ways to make things work, and not, why they will fail. It is a small perception game, but a very powerful one.

The way to craftsmanship is Getting it Done, and not Doing It My Way

Goal-driven Development

Eli Lopian    .NET Tests    

Years ago (well not that many years)…when I was working for a large company, I was asked during my midyear review to identify my goals.

I remember that my immediate reply was to ask for the group’s goals, because with that information I could figure out my own goals, as a member of the team. Looking back, I wonder how they could have asked me for a goal without telling me the larger goals first. The process was with no doubt broken. I remember promising myself that when I become a manager, I will always tell my team the company goals so they can best help achieve them.

But, as time passed by, when I founded Typemock and became the CEO, I must admit that I haven’t always lived up to my word.

My wakeup call was when we had a very large financial project to produce and submit. After we sent the report to our CPA, I received a hysterical phone call from my accountant that my numbers don’t fit. I checked and realized that the reason the numbers were wrong was because the goal was not communicated properly to the people in the company. My team did everything right. They did whatever they could to meet the deadline. They didn’t wait for me. They worked as a team. But I didn’t explain the goals properly.

"Ahhh, so that’s what you meant." A few hours later the numbers were sorted out.

Once I explained the goals and they understood them, they helped fixed the report. If they knew what the goals were from the beginning, the drama would have been avoided.

One of my trusted marketing advisors has a unique and successful tool: the project brief. For every task, he first writes the goals and the sub goals and then the course of action to get there. By sharing the brief, the team has the information they need.

For example, with Test Lint, we want to have web pages for each of our golden rule. Saying that we need a page will probably get us nice pages but the goal is missing. Writing down that the goal of the page will lead to different results. So if our goal is to teach the developer to create great tests, we can explain the reason why the rule exists and how to create tests that follow the rule. Communicating the goal directs the task, and keeps the team focused on the same end result.

As Covey says Start with the End in mind.

The nightmare called Delegating to Contractors

Eli Lopian    .NET Tests    

The answer to ‘How do you decide what to delegate?’ Should be very easy. If it is not one of your core competencies, give it to someone to whom it is. That way, you focus on what you are good at, and they do the same. Yes it’s true, that sometimes the best way to delegate a project is to outsource it.

My way to decide is to ask myself the question “do I want to spend my time coaching, mentoring and growing the required skills in-house?”. If I don’t then the answer is to outsource it.

Take for example graphic design. We don’t have an in-house designer, and while we have talented people on our staff that may be open to learning new skills, keeping a graphic designer, coaching and mentoring him and making sure that he is always growing would not add to our company’s competitive advantage. So we went to outsourcing. Even if we would have hired someone to work in-house, with all the required skills, do we really need to invest in growing and empowering a graphic designer in a software company???

A few posts ago, I posted Boss: Don’t DELEGATE about delegating within the company… So you can only imagine how I feel about delegating to contractors. It’s even harder than delegating in-house.

In order to feel more comfortable and to make it work, the contractor needs to understand the bigger picture and be empowered to deliver the best possible results. In our company, we invite our contractors to the office for a monthly meeting to update them regarding our goals and milestones, and to make clear their roles in achieving them. Communication is the first secret of success. So far these meetings are showing their fruits, our contractors are part of the big picture and it’s the second secret for their success.

But the most important part is, of course, there must be someone in-house that maintains responsibility and manages each and every project or outsource company.

I call it the 200% responsibility. The contractor is responsible for his work, but so is our in-house person that is managing him.

To illustrate the point a non-office issue that can explain the importance of the 200 percent responsibility:

Say I need to pick up my daughter from School and drop her off at home with her mother.

I will stop the car and will make sure that my daughter is safe as she’s crossing the street – my 100%. At the same time, and regardless of me, my wife will be watching my daughter crossing the street from the moment that she leaves the car, until she is with her – 100% responsible. During the time that we are both watching her, while exchanging responsibilities, we are both 100 percents responsible – 200% responsibility. I am 100% responsible for getting her there safely. My wife is 100% responsible for her getting to her safely. There is no room for partial responsibility.

Coming soon: Hiring workers who are expert in fields that you are not, or ‘How to interview potential workers when you don’t understand what they do’.

Leaving the Echo Chamber

Eli Lopian    .NET Tests    

Unfortunately I can’t tell you about our next product as of yet, but I can promise that you will hear about it very soon.

What I can share with you is that following the great success of the Isolator, we weren’t sure what our next product should be. We wanted to help the developer, and yes the first time we got it right, but what next?!

When I first got my iPhone, I was so into it that I found myself using it all the time. One evening I sat in the living room, playing with the apps when my wife said “you are always on the iPhone. I don’t know how to communicate with you anymore.” Before I could reply, my 7 year old daughter said with a huge smile, “through the iPhone!!” What a young marketer, She quickly identified the need and its easiest solution.

We tried to emulate that kind of straightforward thinking when we decided on our next product. It wasn’t easy but eventually we understood that we must actually know and not just assume what the market actually needs.

We conducted marketing research FOR THE FIRST TIME. Leaving the Echo Chamber, we had to check what our target audience wants and what products and services they need.

The process was not easy. A trusted advisor said “I can do that” and then she and I had to convince our team that this was the right step. Convincing everyone was very hard, even when they went to see the focus groups about developers and what their pains are. When we saw the developers’ needs, each one of us saw them through a filter of our preconceived ideas, seeing only what we wanted to see, and reaching individual conclusions.

Finally, we compiled the conclusions to develop THE idea to solve a problem or a pain. Only after we started writing it, we started to understand the power of what we were doing.

A key learning was that we don’t have the same needs of the developers that we develop for. There is a difference between those who build features for developers and the developers themselves.

But if you are reading this blog you have probably already “seen the light”. You probably want to learn how to connect your developers to their customers. They don’t necessarily think or act like you. We are all developers but with different needs.

Breakthrough breaking a wall…

Our here-on-earth mission is to help developers write unit testing that help developers and respect the occupation of development.