Typemock Academy Launch

Eli Lopian    .NET Tests    

It’s been a while since I felt so excited and proud at the same time.  We are three days from the official launch of the Typemock Academy. And even though we’ve been celebrating 5 years of easy unit testing the whole month, and it’s been quite a ride, the Academy launch is a Big step forwards, and a landmark occasion.

It’s been 5 years since I founded Typemock and looking back I can’t believe how much we’ve come forwards. The academy is not just the academy – it symbolizes looking forward, the Future of Typemock.

It wasn’t that long ago that we realized the partners full potential – and here we are, launching the first (of many!) Typemock Partner Academy. As amazing as it seems, we never approached them before or asked them to be our partners. We found out that there are consultants and industry leaders all over the world that are recommending and implementing Typemock’s tools because they realize that that will help their customers. Now it’s our time to organize it, and to give back; by giving them the knowledge, the back up and the tools in order to continue what they do and to help their customers benefit even more from our products.

We are answering the industry’s call. We’re telling you – come and partner with us and support and bring the message of a craftsmanship code to more and more developers all over the world.

See you all there!

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.

Being a Leader is overrated

Eli Lopian    .NET Tests    

Reading a blog post about leadership versus being a boss, I started to think about this matter again. I honestly don’t think that we need any more leaders – we actually need people to execute tasks.

Speaking of leaders, I’d rather call them coaches; coaches are people who understand that their largest task is to grow their team. A coacher doesn’t depend on Good Will, nor will he fix the breakdown or say “WE” instead of I…a coacher will make sure that the team has the tools to find how, and to fix the problem themselves.

The coach is a role model: he never expects others to do what he doesn’t. A coach is the one that turns the triangle upside down and putting himself at the bottom helping  out.

A coach is the one that empowers and will guides. He is the mentor.

Boss, Stop Delegating Work

Eli Lopian    .NET Tests    

My two year old daughter, Rona, is piecing together a puzzle, and she is really frustrated, as she is trying to join two unrelated pieces together. At one point she nearly tore the piece in two, when I saw that I really cringed, she is going to ruin the puzzle. I really have to hold myself back from just taking the piece and doing it myself. But I can’t because if I do, what will she learn? To keep myself from actually just solving the puzzle, I cook dinner and let her work it out herself. It’s frustrating, but I really need to be patient.

I am actually a control freak. Perhaps like many managers I hate the unknown, or to let someone else deal with our tasks. What if he doesn’t do it as well as I can or just the way I do it? What if he doesn’t understand what I need? From my experience, this is normally the case; I don’t get what I want from delegating. When I read about it I found many tactics and checklists like Johanna Rothman (The Delegation Check list)_ The checklist looks fine, but come-on, have you really delegated this way – it is so complicated and you are not guaranteed success if you use the checklist.

So what’s the point of delegating, if I am still worried if the work is being done and need to check every step they take? I’ll just do it myself and just get it done. Sound familiar? So how do I delegate work? Well I don’t, or I try not to, because you can’t really delegate work.

So delegating is critical to success. You simply can’t do everything yourself. But it is impossible to delegate, how I get out of this tangle; I am beginning to feel like Rona and her puzzle. This is where is hit me, you can’t delegate work, but you can empower people, you can delegate responsibility. Delegating responsibility is simple, but it required a lot of patience to empower people.
1. Tell the person the end result that you expect,
2. Ask them if they can be responsible for it.
3. Ask them when they think it will be ready.
Wait…

For example:
1. “To get more developer to write unit tests, we need it to be easy to write the fake statements”
2.”Can you be responsible for that?”
(Here you will get many questions…)
3. “When do you think it will be ready?”
(Work with them to break down and prioritize tasks, or wait till they do it themselves)

This way we turned things around, your staff member should come to you and ask you what he needs to do in order to get the project done, instead of the other way around. The employee needs to come up with the questions. You shouldn’t have to lead him.

Let them lead. I know it can be scary, and things will move more slowly at first. But as they build and execute their plan, they learn. A good manager lets his employees make mistakes as part of the empowering process.

It’s hard to let go. But when you understand that as a manager, it is your job to empower and grow your team, you will learn to sharpen your swords instead of cutting down the trees yourself. Sharpening the swords takes a lot of patience, but when you take a step back and look logically, you can see the need.

I still trip on the slippery hill of delegation. It’s really hard to stay out of their way and let them work.

The best delegation is when you give a responsibility that is a bit higher then what the employer himself believes that he can handle. As I say: I believe that my team can do more then what they themselves believe. The message you deliver is that you believe in him. They might fail once or twice but by the third time, you have another empowered employee that can do much more than he ever thought he could. That is, as long as he has the necessary abilities, he will not fail. But you will need patience just like I need with my two years old, and after all, I’m not asking my two year old to cook dinner, but to finish a puzzle.

Debugging Communication Errors

Eli Lopian    .NET Tests, Community, Debugging, Management for Geeks, Time Management, Unit Tests    

I couldn’t sleep all night, thinking that on the last company meeting, when one of my employees complained that he can’t finish his tasks because of personal issues that he has with other employees,  I basically told him and the rest of the team to help each other and be a team, I was managing them instead of empowering them, and knew that the issue probably remains unresolved…

For the next meeting, I decided that no matter what I do, I will make sure that my team goes back to work after they resolved their issues themselves, empowered to continue working and achieving  their goals.

I started the meeting by asking each of them to bring up a personal issue that he has with another employee and to resolve it with the other on the spot. It was amazingly interesting to see how they raised the problems, and found the solution at the same time.

One of the employees complained that he requested help via email. He sent the email, but didn’t receive any answers. He needed certain people in the company to fill out part of a form, but none of them did. Nothing but a simple communication problem; they all got the email but didn’t understand the call for action. His way to resolve the matter was to sit with each one of the people involved personally and to fill the form together, that way he will make sure that they understand their share, and he will make sure that it’s done on time.

One of the developers complained about having troubles with managing his time.  I explained that this is not an interpersonal problem, and asked him questions which led him to realize that his lack of time is because he is always helping people. He can’t say no to anyone, and he doesn’t want to look bad or disappoint anyone, so he ends up making everybody happy by helping them, but having no time to do his own tasks. When he understood, it was a major breakthrough, and he realized that he will have to start saying no to people or at least to say I’m busy now I will help you later; I would love to follow and see if he would really do it…

It’s only two examples out of many. The amazing and inspiring part was to see how each one of them was empowered and found his own way to resolve his problem without being told or managed.

Last, out of the entire company there was one developer that claimed that he has no personal issues with anyone in the company. When I asked him if others has problems with him, he was confident that their answer would be no.

On the second round that we did, each one of the developers needed to share their successful interpersonal communications, almost everyone mentioned him.  I guess that it was as obvious to them as it was to him.

One of the more gratifying surprises from the exercise was hearing about the successful communication routes that have developed that I did not know about.  For example, two developers found the time and were sensitive enough to help a third that was in major distress.  They simply encouraged him, but it was exactly what he needed in order to get back on track.   Another developer thanked the sales team for providing him with relevant historical customer support information.  Yet another thanked a team member in marketing for helping him with the wording in an important email to customers.

By the end of the process, it was clear that the team understood the power of effective communication and they now had better tools to resolve interpersonal issues with team members independently.  And at Typemock we know – your result (read: code) is always better when you’re working with the right tools.

When you know immediately when something is wrong, you are able to fix it, and get an immediate indication that your code is correct without the involvement of the QA. In other words, exactly like the Manager that empowered his team to resolve their problems without his involvement and without managing them, the unit testing helping the developers’ resolve problems on the spot and avoid QA involvement.

Will liability change everything?

Eli Lopian    .NET Tests    

Some software application bug must have really pissed of Commissioners Viviane Reding and Meglena Kuneva as they want software developers to be held liable for the security and efficacy of their product.

Alen Cox, one of the leading Linux kernel developers argues against the liability. “Closed-source companies could not be held liable for their code because of the effect this would have on third-party vendor relationships”

Bruce Schneier has a really good article about the commercial effect of liability. In short the commercial cost of fixing your bugs is not as economic (they never heard of Typemock) as adding a new feature, but having a liability law will change this cost and force more CEO’s to spend more money on the quality of their code.

"We’re making software as secure as we possibly can. People don’t look at window-lock makers for the responsibility for burglary — the responsibility tends to rest with perpetrators," said Jerry Fishenden Microsoft’s national technology officer

Are we doing the best we can?

So, are we doing the best we possibly can? Should software developers be liable when they are sloppy and non professional. A doctor is liable if he makes a mistake, we should be liable if we are sloppy?

As an industry we still have a long way to reach the standards that we already have in specific markets, MISRA, DO-178B, PCI, Sarbanes-Oxley and FDA’s medical device standard. Should the software industry create or adopt a standard to draw the line of liability?

If we did have this standard, what would you say would be the minimum required actions that we have to do, to be exempt from liability? What would define a professional vs a sloppy developer.

Isolate your ASP.NET – Race for Free Licenses

Eli Lopian    .NET Tests, Release    

Our team is launching a new product for ASP.NET developers who develop with integrity – the ASP.NET Bundle.

For the launch you can win FREE licenses if you are fast enough.

See our official blog with the detail on getting free licenses.

Good luck…