The right product

Once upon a time, a long time ago in a state not that far away, I was approached by the technical lead for a startup. The company was having problems shipping their product, they kept missing deadlines and had a slew of bugs. Their board of investors was getting frustrated, and he was under a lot of pressure.

Could I help?

Sure, that sounds right up my alley.

The lead said that he was really busy, but would get me access to things as soon as he got back to his laptop. Latter that evening I got an email with access to their git repository, and a request that I "have a look" and see if I could fix things. Now it is always a bad sign when someone wants you to just "have a look" and make it work. I responded to him right away and said that while I know he is really busy, for me to be of any help I'll need to understand what the code is supposed to do, what isn't working, what the business's goals are, and get an introduction to the rest of the team.

He was really busy but we got a meeting together in the next day or so. It turns out that the technical lead is the only US based person on the technical team. He is generally kept too busy to write any code, and they have outsourced all development to a company in Costa Rica. The trouble as he sees it is that the development company is constantly behind schedule, and hasn't been able to deliver anything that "works". The investors have poured about a quarter million into the project, and are getting anxious about the continually slipping deadlines.

We really need to have it working and demo-able by the end of next week for the investor's meeting.

So, what is the software supposed to do? It is a blogging platform. The backers own several small printing companies who have seen declining revenue over the last five or so years, as people move to blogging and to putting stuff on the "internet". The goal is a major marketing effort, and a new revenue stream. Their blogging platform makes it "simple and easy" to print your entire blog, a single click to turn it into an attractive, printed "scrapbook". They are sure that bloggers, especially moms putting lots of family memories online will want an easy way to make a more permanent record. They also plan for the blogging platform to be an independent revenue stream, they will charge a monthly subscription service and make millions! — I call this state of mind "founderitis" an intense belief in millions to come causing people to forget about the practical business at hand.

Okay...

It turns out that they don't have an issue tracker, or a spec. The board of investors and the leads boss — "the business guy" have just been giving the lead a stream of ideas, which he has translated to the firm in Costa Rica, who is actually building the platform. There is a setup script in the repo and it kinda gets the software up and running... Once up you can view a blog, the system isn't multi-user yet, so there is just one blog. There are a few themes that you can apply to your blog, but only the default one works, and if you know how to work around a few bugs — the tech lead has the steps in his notes — make a post. Lately they have been doing a lot of work on this WYSIWYG print layout editor, the ideas is that it will let you adjust a post's print template and see it in real time.

To be clear you can't actually:

• Make a post, at least not without the work arounds in the tech leads notes.
• Comment on a post
• Have more than one blog/one user on the "platform"
• or print the blog.

The layout editor doesn't work yet, and it isn't connected to anything on the print company side, they don't have an API or anything, so it will probably just generate a PDF or something (insert something hand wavy).

All of this after just 18 months of development and ~$250,000.

Well, lets pop the hood and see if there is more to the story in the code. Maybe they are further along than the lead realizes. Hmm... it's some 400,000 lines! It's all PHP, and very object oriented. There is an extensive class hierarchies, everything has an abstract class, an interfaces everywhere etc. It looks like a bunch of Java programmers where forced to write PHP, and where being paid by the line.

As a side note all the comments & documentation are in Spanish, though none of it appears very useful.

After half an hour or so it is clear. I don't know how many people they had working on this, but with typical Costa Rican rates, 18 months, and a couple hundred thousand USD they probably had a team of 8 - 10, or maybe even more, writing lots of code every day. The ratio of code to functionality is huge, it's not anywhere near being ready to run. There is no way we are going to be able to demo this by next Friday!

I call the lead back right away, and start explaining to him what things look like, and detail some options. He quickly turns taciturn and says, no, it almost works, see, he can partially demo the layout engine on his computer! He and the dev's have been working hard! This is close to production ready. Surely I can get it stable and working for the demo!

I reiterate that what he has is a mess, but that... he cuts me off and says "fine, but you will have to talk to my boss, the investors representative." Ok, that sounds good. He'll give his boss my number and he is sure that I'll get a call shortly. He makes it sound like it will be my just deserts.

Within the next few of hours I receive a call. It starts out well, introductions back and forth, and then a detail of the real state of the software. After the bad news I point how that things aren't irredeemable, building a blog isn't particularly challenging. It is just possible that in the week we have before the demo that we could build a blogging platform, including support for multiple users, creating posts, adding comments etc. I also suggest that a more direct path to his investor's goals might be to integrate with existing blog platform, such as Wordpress. That will be much easier then requiring users to migrate their content to this new platform, and it would be less work to build.

Unfortunately our conversation deteriorates rapidly into him shouting and cursing. He says his investors are likely to sue him for malfeasance if I don't fix this by next Friday and if I don't fix it on time he'll make sure everyone knows what a fraud I am and how I'll never work in the Salt Lake City tech scene again...

I wrap up the conversation making sure he knows that I won't be working on the project. I never found out what happened to the start up, but I know the lead dev was looking for work a few months latter. I did have one client that I was courting at the time that abruptly went dark — they knew the tech lead and had heard "bad things" about me, however I was able explain the situation and ended up working with them for many years.

It's a fun story, complete with a screaming executive, financial loss and lots of Costa Rican code, all of which are real. Like any good story, it ought to have a moral. There is a saying in the aircraft industry that behind every crash are 7 mistakes. Lets look at some of what went wrong for this company.

A culture of being too busy to do the important things. The value the company was trying to create was a blogging platform. Given 18 months of full-time effort, the tech lead should have been able to write the software on his own, and have a far more complete solution. What happened? The tech lead spent those 18 months rushing to answer emails from the board of investors, finding an outsourcing company, answering their questions, reviewing their code, and a thousand other tasks. Being busy is an easy trap to fall into, particularly for a young company without customers where it is hard to know what is actually making a difference. Keep your eye on what is actually creating value, do that, and measure.

An executive that couldn't receive feedback from his lead engineer. This is a basic leadership/management issue but unfortunately it also appears to be very common. When talking to the boss is a form of punishment the boss isn't going to hear what he or she needs to, to make the correct decisions for the company.

No specs. This is one of the leading causes of all software project failures. It is the business's responsibility to provide the IT team with a written description of the functionality they need. It needs to be a written spec. The act if writing it out will have a clarifying effect for the business people, will aid in communicating the spec clearly to all those involved, and allows discussion and editing. Ignore this at your peril, too many do.

No milestones. In a sense the project had only one deadline, it was after 18 months and more than $250,000 dollars worth of work, and they missed it. Had they made monthly deadlines they would have missed 18, but the investors would have know that there where serious problems 15 months earlier. Had the expectation been set that the team would show their work every week, they would have missed 72 deadlines, and the investors could have detected the issue — and helped to corrected it — within the first month. Breaking up a project into pieces that can be, and then are, delivered regularly tremendously improves the chances of the project's success. Personally I find that a week is a good, and very human schedule to plan on. Lets demo what we did this week every Friday.

Building the wrong thing. The prior points are all about execution, but even if that had been flawless, would they have reached their goals? I don't think so. At the time — and to this day — Wordpress dominates the blogging & small website space. At the time Wordpress powered about 12% of all websites, while today that number has risen to about 30%. How much better do you have to be to compete with a product that is free, that is an industry standard, and has a huge ecosystem? Wordpress should have been their opportunity, rather than their competition. Had they instead focused on adding easy printing capabilities to Wordpress, I expect they would still be around today.