Unit testing is such a nice idea. Developers create tests as they develop working software. Then they (tests, not developers) are executed during every build and it’s verified whether something hasn’t been broken over the way.

Unfortunately unit tests very often doesn’t work well even when team formally boast they employ this practice. Why?

1. Unit testing can’t be enforced. Yes, yes, I have heard about tools which measure code coverage. A problem is they tell you whether your code is covered but they don’t tell you with what. It can be covered with quality tests but odds are it is covered with a lot of crap generated just for the sake of achieving target code coverage. Remember you get what you measure.

2. Writing unit tests is easy – maintaining them is a hard part. Consider you have your code and your tests perfectly working. Now you change something which breaks several tests. Is that a flaw in the code? Or maybe it was done on purpose and now you have to rethink and rewrite all broken tests. Heck lot work to do.

3. Tests should be added all the time. When you find a bug which wasn’t caught by tests you already have you should add one which will do it in the future. And yes, that means more work on crappy maintenance tasks which is neither funny nor developing.

4. It takes so long to run all unit tests. Sometimes tests are switched off because build process takes too long and they don’t have to be run each time, right? Well, wrong. They have to.

5. Good unit test checks border condition while easy-to-write unit test exploits optimistic scenario. It’s pretty easy to write unit tests not using your mind at all. 2 plus 2 should be 4. Task completed. Case closed. How about using 0 or negative numbers or floats? Forget about them – too much work.

6. Writing unit tests is boring. That’s not amusing or challenging algorithmic problem. That’s not cool hacking trick which you can show off with in front of your geeky friends. That’s not a new technology which gets a lot of buzz. It’s boring. People don’t like boring things. People tend to skip them.

A key thing to have unit testing implemented well as a practice is right approach of developers. Unfortunately it can’t be trained. These lads and gals either believe unit testing helps them to create good software and they do their best to develop high quality unit tests or they just cover the app with some crap just to get proper code coverage result and pull the problem out of their ass.

If you’re going to use unit test better be sure your people are the former. Other way around it’s not worth the effort.

Vast majority of people working on software products contact their customers directly or indirectly. Yes, software developers included. Each time we do it we play a role of salespeople. Of course customers don’t see us making product presentations or negotiating prices. What do they see then?

In my case answer is pretty easy since my attitude was commented several times in the past by my colleagues. I’m too honest and too straightforward. It’s definitely a mixed blessing if that’s a blessing at all.

Talking about business is expected to be like old-school negotiations. Two parties sitting on two ends of the table trying to squeeze others as much as possible using all tricks they know. I hate it. I dream about this kind of discussion:

– We can do it in 4 months. Here’s proposed schedule.
– Are you sure phase 2 has to take so long?
– Yes, since we have to develop integration module for external system. It could be probably a bit shorter if we had experts of that system available but we’ve worked with these guys before and there are always problems with them. If they won’t be an issue this time we should be able to deliver 2 weeks earlier but I wouldn’t bet.
– OK. Another issue is the price. We won’t pay more than $100000. That’s our approved budget.
– Let me think… We’d need to cut some functionality out of scope to make it a win-win. How about messaging module and these complex reports?
– Um… we can let reports go but messaging module must stay. Deal?
– Deal.

Yes, I know, I am dreaming. Anyway I often try to bring this kind of approach to the table. Too often. You shouldn’t be surprised if you’re a customer and I ask you: “We plan to develop this product for you, does it makes any sense for you or is that just a brain dead idea?” I may also state: “This function would make both your and our lives easier, although I don’t believe they’d allow me to do it for free. Would you find some budget for the feature? I promise the price will be good.”

On the side note, if you ever worked as a salesperson with me I know, you already hate me. I guess I must live with that.

This approach may weaken negotiating position of my party. Sometimes it is considered as pretty harsh by customers since you occasionally don’t wrap up the truth with nice marketing blah-blah (“No, we won’t build and deploy complex telecommunication solution in a month”). That isn’t playing by the rules and from time to time people find it hard to deal with it at the beginning.

However the thing I found out is that when a relation with the customer is already built they start to appreciate this attitude. Having an honest source of information on the other side is quite a valuable thing. Even when the guy is sometimes too honest and too straightforward.

It doesn’t mean I’m totally happy with it. It definitely would be better if there were no scary ‘too’ word in the label they stick to my back.

What kind of person are you? What do your customer see when they talk with you?

A developer who sends an email to a customer to elucidate some details of proposed solution. He is a salesman.

A project manager who goes on biweekly status meeting. She is a saleswoman too.

A support engineer who answer for ticket submitted by one of clients. Guess what, he’s a salesman.

A manager of software development team who receives escalation call from disappointed customer. Surprise, surprise, she’s a saleswoman.

It doesn’t really sound as they all were salespeople but they are. Whenever we contact current or potential customers we all play role of salespeople at least a bit. It doesn’t mean we all should wear suits and have this marketing blah-blah talk ready to fire at the customer. It doesn’t mean we should all have minds set for thinking what product we could up-sell there. But it does mean people on the other side will evaluate our work as the part of current and future sale process.

“We’ve done a project with them and we won’t do another.” Odds are that’s not the fault of sales representative alone, but developers or support engineers or project managers or all of them screwed their work. They failed at up-selling anything more, no matter how great their product could be.

“We considered them as a company suitable for small projects only but they’ve proven their worth and now they’re one of our important vendors.” Oh, that wasn’t only the effort of key account manager responsible for that customer. Or was it?

Even when our work isn’t seen directly by the customer it works that way. If a quality engineer does a perfectly good job hunting all the glitches it will be appreciated as an effort invested into high-quality. The company will be considered as one of these which delivers quality solutions (even when they aren’t always on time) and that’s pretty important factor when customer chooses a vendor. Or at least it should be.

In this way or another we all help in selling our products. Most of the time we do that unconsciously but it doesn’t change our influence on setting new deals. We all are salespeople.

It is said that formal agreements are for bad times. As far as everything goes well we can forget about papers even when there are some of these. Either way it’s all about trust.

A question: what happens when a subcontractor doesn’t do their work well? Do you take a signed papers and count forfeits? Or you trust them and you believe you can find a solution which is acceptable for both sides?

What about relations with your bosses or your customers?

Probably in each situation we have a different level of pain. Sometimes we’d use our formal weapons faster, sometimes we’d try to avoid that as long as possible. Where’s the difference? Trust. The more you trust someone the longer you’ll be talking with them as human with another human, not as lawyer with another lawyer.

There are people who you don’t trust much, maybe you just don’t know them or they let you down before. When doing business with them you’d focus on formal agreements much. There are those who you don’t trust at all and you won’t do anything with them even if they’d pay you well. Of course there are also people who you trust much and their word weights even more than signed paper.

Which kind of people do you work for now? Which kind would like to work for? If answers differ think about it.

Somehow my recent discussions are mostly about estimating. Last discussion on PM Clinic happens to be on the very same subject. It reminded me about great technique which can improve your software estimates. It is called Evidence Based Scheduling and I’ve learned this from Joel Spolsky’s article.

The basic concept is pretty simple. Jack the Developer gets the task. Actually a bunch of them. He delivers his estimates basing on his guts. Estimates are most likely crappy but at the moment it doesn’t matter much. As Jack does his work he tracks how much time he really spends on the task. It may happen it takes two days instead of planned 4-hour effort. Velocity for this task is 0,25 and it goes to the history of Jack. When Jack’s history is long enough you can use it to judge how crappy his estimates are.

Evidence Based Scheduling uses Monte Carlo simulation which takes some effort to calculate results. However Joel brings some good news here:

“Most estimators get the scale wrong but the relative estimates right. Everything takes longer than expected. (…) This common estimator has very consistent velocities, but they’re below 1.0. For example, {0.6, 0.5, 0.6, 0.6, 0.5, 0.6, 0.7, 0.6}”

After completing a dozen of tasks you can get pretty much insight which number you should use to multiply Jack’s estimates to get something close to reality. Of course full-blown simulation will probably lead to better results but you get the idea.

There’s one more gem in Joel’s posting which is worth stressing:

“Fix bugs as you find them, and charge the time back to the original task. You can’t schedule a single bug fix in advance, because you don’t know what bugs you’re going to have. When bugs are found in new code, charge the time to the original task that you implemented incorrectly. This will help EBS predict the time it takes to get fully debugged code, not just working code.”

I know it brings quite a lot of effort for Jack the Developer, since sometimes he fixes bugs really fast and accounting time spent on each bug fix to proper original task adds enough hassle to be reluctant to do so. However the ends are worth means this time.

I strongly recommend you reading whole article as it delivers all the details about Evidence Based Scheduling.

OK, this one is controversial. Software estimating. How to do it good, or good enough? First of all, when talking about the subject we all can learn a lot from Glen Alleman who bring quite an uncommon perspective to the area as he’s based in industries which tolerate missed deadlines with much less patience than the average.

Now, what’s the point? If you asked me how software estimating should be done I’d direct you to Steve McConnell book on the subject. Believe me or not, he didn’t write anything good (if anything at all) about role of wild guessing in software estimation. Which doesn’t make me avoiding wild guesses at all times.

Actually sometimes I make good use of them.

Now, go flame me.

What’s the use of wild guesses instead of proper estimation? Wild guesses don’t have to be so wild if you ask a right person. If I ask my development manager how long something would take and it’s a piece of software he’s fairly familiar with in vast majority of cases he’ll come with some guess. It should be reasonable enough to judge whether it’d take 9 months to do the job or rather just a few weeks.

I don’t consider that as a full-blown estimate. It’s hard to use it as a base to create a schedule but still it’s a valuable feedback to judge whether and when your team is capable to overtake the project or decide if the whole thing is worth further presales effort. If you need to develop a bunch of tools which your competitors already have in their product portfolio chances are good you won’t match their schedules and/or prices. If you add that your team is backed up for the next half of the year it’s probably not worth investing effort to do more than just getting first coarse-grained approximation.

Yes, every wild guess should be considered very carefully since after all it’s, well, just a wild guess not an estimate done according to rules. However doing proper estimation is quite an effort and sometimes you need something rough but quick instead of exact but demanding.

And remember: don’t ever, ever allow your wild guesses to be sent to sales department.

Who should be a leader of a startup? An easy question. One of founders. Or even better each of them. They are naturally predestined to leading role. They got the idea. They own the company. They keep all things running.

Now the more important question: what kind of leaders are they?

Why is it so important you ask? Well, having a great idea, being a CEO of a company and managing it on a daily basis tells you nothing about leadership. You can end up working either for a great leader or for a sick asshole. No matter which one is true as far as the startup has money leaders won’t change anytime soon.

Because of a small size of the startup role of leaders is defined a bit differently. Not only they motivate their teams and set up a strategy of the company but they’re also personally responsible for building company culture and enabling company growth.

In a big organization one asshole doesn’t make much difference – you either work for dozens of them or he’s going to be the only low-performer among great leaders. In a big organizations company culture is already set and it takes a lot of effort and a lot of people to change it (for better or worse). In a big organization one person won’t hamper growth even if that’s CEO who believes leadership is all about yelling at people.

In a startup one person makes a difference if he leads the company. If he’s a sick weirdo don’t expect healthy atmosphere all over the place. If he makes working for him a hell you won’t see many long-runners in the team as everyone comes and goes as soon as they realize things just won’t change with that kind of boss. In small organizations poor leaders are the main reason why companies suck.

If you worked for a person who is physically unable to build anything bigger than a couple dozens of people or creating healthy atmosphere at work you exactly know what I’m talking about. Big corporations can be filled with these types and they’ll manage. Startups don’t have luxury to be lead be them.

That’s a final post of Entreprenurs Time series. I hope you’ve enjoyed it. Please leave your feedback and let me know whether I should post this kind of series in the future.

Last time I shared mistakes we made while working on Overto – startup which was closed down some time ago. Today another part – things we did right and are worth replaying next time I’ll be engaged in a startup.

Setting up a company behind

Setting a company, which is quite an effort in Poland, from the very beginning was really a good idea. All founders knew each other well so lack of trust wasn’t the main reason standing behind the decision. We just wanted to give ourselves a bit of motivation making it a real business. However thing we didn’t really plan was that we gained much credibility showing company’s details instead of letting people think the whole thing was created by some student during holidays and won’t be supported in any way in future. Seeing a company behind a service doesn’t guarantee you it won’t die but at least you can be sure someone cares.

Long discussions before start

Before launching the project we had very long discussions about what we plan to do and how we want to do it. Of course not every detail was checked but when I compare Overto to other startupish projects I was working on it was really well-thought at the beginning.

Wide range of roles covered with our experience

We had really good pack to run an internet service. Development, administration, user support – in all those areas we had experience from the past. There weren’t many things which could have surprise us. We weren’t forced to look for a specialist in any technical aspect of building our application.

Working in the same place

For some time we worked in the same building which helped much in decision-making process. We could all meet ad-hoc whenever something important had to be decided. After some time we spread among different places and suddenly we saw how much value was in working in the same office.

Despite we invested some money to fund the project I don’t treat it as a loss. For experience I gained it was a low price. Another time when I’ll decide to jump to that kind of project chances of success will be bigger.

First part of lessons learned from startup failure

Whole Entrepreneurs Time series.

Some time ago we closed down Overto – startup I was involved in. It was a failure – pretty obvious thing since we’ve closed the service. Since we learn much on our mistakes I think a reliable analysis why the business have failed should be valuable for you. For the beginning things we screwed.

No one working full time

From the very beginning we knew none of people engaged is willing to leave their daily jobs to commit fully to the startup. We thought we’d able to run internet service after hours. To some point that was true. As far as nothing bad was happening with the servers and the application it was all fine. We were working on new features when we had enough free time. Problems started when we faced some issues with our infrastructure. We weren’t able to resolve issues on the fly and had several downtimes. You can guess how it influenced user experience. That also backfired on service development since we had to focus on current problems instead of adding new functionalities. Lack of person working full-time and being able to deal with maintenance and bug fixing was the most important reason of failure.

Catching the market

That’s partially a consequence of the previous point. Since we spent majority of our limited time on trying to keep the service running we weren’t able to catch the changing market. We needed to cover new areas to move the application to another level but we couldn’t complete ongoing development. The whole project stopped in beta version and for users it didn’t look like anything was about to change.

Lack of marketing skills

Thin line between life and death of internet service is a number of users. For the initial period of time the numbers were growing systematically. Then we hit the ceiling of what we could achieve effortlessly. It was a time to do some marketing. Unfortunately no one of us was skilled in that area. Even worse, no one had enough time to fill the gap. That would be another stopper if we dealt with the problems mentioned above.

Business model

We hadn’t checked very well a business model we set up on the beginning. We were surprised a couple of our features weren’t as unique as we’d initially thought. Ironically that wasn’t a big problem since we had a bunch of ideas how to adjust the strategy in a new situation. Anyway, you should plan to change your initial business model.

Screwed chance of selling the business

After we’d decided we won’t be able to maintain the service in the long run we had a chance to sell it. To make a long story short we screwed negotiations starting with way too high price. We thought more about how much work we put into the project than how much it can be worth for potential buyers. Things are worth as much as one’s willing to pay for them, no matter how long it took you to produce them.

Waiting too long with final decisions

I think that one is a bit sentimental. Since the service was our child we were reluctant to make a decision about closing it faster and limit losses. We’ve been tricking ourselves thinking that everything would be fine while we couldn’t get the application back to work properly.

Second part of lessons learned from startup failure

Whole Entrepreneurs Time series.