Slow down to go fast.

Too long ago, I was starting a new sport - Dirt bike riding.

Intensive, extreme, physically punishing and amazingly rewarding sport, with lots of skills to learn.

During one of my first rides, in between trees, rocks and trails, one of the riders gave me a tip I do not practice often enough:

To go fast, you also need to learn how to ride really slow.

This actually makes perfect sense. You need to practice every nuance of your ride, do it right and repeat, until doing it fast becomes trivial.

However, if you want to improve, from time to time you need to slow down and review what you've been doing thoughtless - You might find out you're doing something wrong there.

Sometimes you need to go back to the things you do quickly on auto pilot and do them slow and methodic.
You might find out you can still improve.

How Netflix cracked the formula for hit shows

I'm a sucker for comics. Specifically super hero comics. And, after seeing Netflix's Daredevil, I was taken by how accurate and well done it is. It's one of the best adaptations I've seen to a comic series. Fast paced, good action, just blunt and dark enough.

That got me thinking - How the hell did they do that? After "Orange is the new black" and "House of cards", Netflix seem to be churning out great TV, again and again.

The answer is simple. Netflix, which started as a mail rental service (Just because broadband infrastructure wasn't relevant back then) and moved on to online video rental, simply know exactly what we want as viewers.
They know which movies we like.
Which movies we watch until the end, and which movies we "break" in the middle.
They also know which scenes we run over and over again.

By tagging every scene in every content, they have the ability to create the perfect show for each one of their viewers. They can actually make script decisions (Exactly how the story will be built) according to data.

Furthermore - In the future, story would not be linear as we know it, but every subscriber will get his own, personal, customised version of the show. Yoni Bloch's Interlude might actually close this gap from the production end.

That's pretty amazing.

Recruitment - A different take

Growing as a company could sometimes be difficult.
You need to be able to recruit people (Or outsource them, which will not be handled in this post), train them and get them to be productive as fast as you can.

For a small startup, this is even harder - Every position counts, and every worker might be responsible for great success, or miserable failure. This can make the recruitment decision a very critical one.

For our next recruit, which should be a tier 3 support engineer, we've decided to handle the process a bit differently.

First, we decided to describe the typical workday for the position. What the person would do when he comes to the office, which would be his tasks, how would he work. We write that down.

After that analysis, we focus on what he (Or she) needs to know in order to perform his tasks. It could be deep knowledge of our product, SQL know how, MS Office skills or whatever. Divide those skills into skills he would need to know "From home", generic skills that could be taught, and specific (Our product) know how.

Once we know that, we can actually start looking for the right person. The search would be much more focused, as a lot of skills which you might consider as prerequisites will be shed during the process.
We would also have a clear training plan for that person.

In the end, I love to say that I'm looking for excellent PEOPLE - As most skills could be taught.

Happy hunting!

Way too lean.

Everyone's going lean these days. Work lean and cheap, go to market as quickly as possible, fail fast.
While this approach works great in our time and age, it causes a lot of products (Jelly, for example) to come half baked.
The philosophy behind it is correct. Test the market as fast as you can, to validate your idea and gain ground. If you fail enough times, you might even succeed once. And one good success is all you need, right? (Yes, I am being ironic.)

However, unless your service goes ballistic right after launch, you might never know if it works or not. Hell, even if it does - What's your measure of success?

99% of the apps do not pass the 10000 download barrier. So what does success mean? You might fail your product a bit too fast there. You might even not know why it failed.

My advice would be to be a bit more thorough about your product. Get real feedback from as many people as you can (2nd hand friends are even better, as they don't owe you anything. You can even pay a symbolic token like a t shirt or something).

Don't launch too early, don't fail too fast. Thinking twice might not align with the cranky, wham bam lean approach, but might save you a lot of time and heartache.

Deliberate Mistake, correct end result

I've spent my army service days as an infantry soldier.
A lot of my unit's field practice included night navigation - Where you learn a path (By heart), and sent to navigate few miles at night, and collect a few waypoints.

The most challenging part of these drills was not walking with 35 pounds of gear on, or even seeing what's ahead of you to avoid pitfalls. It was memorising the path, and walking through it - If you don't know everything by heart (Sometimes you only have 20 minutes to prepare your gear and learn the path), you're bound to get lost. If you get lost, you walk more. If you walk more, you'll be more tired. And so begins a downward spiral no one likes.

I found that the most effective way for me to study these paths was using the deliberate mistake method: Where you choose a point on the map that's easy to recognise and reach, and from there walk to the nearest waypoints. This would sometimes mean walking more than the 'direct' approach, but you'd be less likely to forget a turn or a hill, and less 'marks' to count when you're walking, at night, with your gear on.

Nowadays, sometimes when I look at decisions I need to make, I sometimes take the 'wrong' decision, to reach a larger goal sooner - Like coding some ugly patch - I know I can correct this mistake later, but I also know I would also reach my goals on time, with confidence.

You can stop developing your product now, thanks.

Once a startup's MVP has been released, there's always the question of what's next.
A lot of startups tend to use the time after sorting out the quirks and the bugs to develop more features and enrich the product.

But sometimes, adding more features to your product before even finding out what works will only distract your new users, who are trying to get to know your product.

A good example might be Google Plus vs. Twitter.

Twitter has remained essentially the same as it's been since its inception. Google Plus has overhauled completely more than once, and is crammed with tons of features. While Google stuffed its social network with more and more features (Share and video and an amazing image viewer and more menus and what not), and how to implement them different than Facebook, Twitter focused on refining its mobile and web experience.

So next time your R&D department got spare time, have them improve performance, clean up code and take care of automation and scale rather than add more buttons and features that might just make your product too rich and too redundant.

Your users will appreciate more if they wait 1 second instead of 5 for a response rather than another copycat feature.

DO NOT UPGRADE!

Too often, when an application fails on memory or performs poorly, the immediate solution would be upgrading the machine.
Add more cores, more memory - And think that this would clear the problem from under the rug.

This strategy actually causes even more damage - As you will have to deal with the real issue (YOUR CODE...) later, when the system has more data, more angry clients, and more code that breaks.

If your application consumes too much CPU, you should profile it and solve the problem.
If your application leaks memory, you should find out where.

Taking the lazy approach would cause you credibility issues once you will really need that upgrade.

Rewrite your Product, and live to tell about it

In every organisation life, there comes a time when its product is due to a big overhaul.
From dated GUI to dying Database, a Business Logic layer that's filled with patches, or even personal changes ('The only girl that knew that code has left...').
So now the company gives you, her beloved manager, a clean slate to rewrite the product.

Supposedly a dream come true, right?
In a past post, I've discussed the new system dilemma, a situation where you're already knee deep inside the rewrite, and pressure is rising.

This post should help you avoid that terrible situation.

The most important rule when writing a product from scratch is deciding what it's NOT going to do in phase one (See time frame in the second rule). Trying to match all the features the old system supports (Sometimes while it's still being developed by tier 4) will result in an endless effort.
Focus, and be transparent with what you'll deliver and what you won't. Put an emphasis on what your rewrite brings to the table that the old stack doesn't.

The second most important rule is DON'T LINGER. 3 months. Show something (Even a playable mockup) after 1 month. Show progress every week.
Three months is a long time, and mind that things can change, but it's a short enough time frame that things won't turn completely around.

When phase one is near the end, you can "Let the company in" and plan the next stages.

Focus and Agility bring results. Go for it!

Draw me a unicorn

The recent talk about unicorns - Startups which passed the 1 Billion dollar valuation - Have started a goose chase by many VCs. Series A VCs are no longer interested in companies which would give them 5x return (ie - be part of a 5 Million $ investment, and receive 25 Million as part of a company's exit), but they need more than that.
So VCs are no longer looking for teams which can build 50 Million businesses, but a billion dollar business.

While that might make sense financial wise, it may actually kill the whole VC business, which is already dying. Super angles and private equity investors are already taking their place not just in seed but also in series A.
Startups might just be better like that.

YULES.CO is up - Check it out!

Got a new self promotion website.
Currently quite generic, but much more coming soon:
A more visual timeline of my career, and blog might also move there (though I really like the advantages of the Blogger platform).

Come visit me at www.yules.co. More to come soon!

Tunnel vision

During the life cycle of a 'live' system, things tend to break.
Sometimes because you've missed something, sometimes because you didn't get to test that bit of code. But whenever a system turns live, after a while (Sometimes it happens pretty quick...) the system needs to handle something you haven't tested.
Sometimes even an unexpected failure. Sometimes network lagging causing timing issues.

Few of these times, you encounter what I would like to call a gremlin. That's this illusive bug which impacts your system, occurs enough times a day to be considered as a problem, but not enough so it's easy to reproduce.

The worst thing programmers love to do is mark it as 'irreproducible', throw it back at the QA, and do something else.

Advice for this stage: Don't. QA would probably not be able to reproduce it, and even if they would, it would be difficult for them to do it in a consistent manner so that you'll be able to gain from it. You need to help them. These things escalate fast, so don't put yourself in the position of the developer who tried to put the mess under the rug.

Start digging. And sometimes, the solution requires processing through endless logs (Or even add these logs). Sometimes a lot of code is involved. And after a few hours, if you still haven't found it, you find yourself repeating your actions, adding more logs, running sequences again. You've entered a stage of tunnel vision, where you can't look around.

Best advice for this stage: Stop. Go get coffee, go home, call someone, take a break. My best solutions came from getting some distance from the problem I've been working on, in order to clear my vision and be able to try a new approach. Another fresh set of eyes could work as well.

Happy hunting.

The real cost of user acquisition

Companies spend a lot of money on user acquisition.
From expensive ad campaigns, to shows and events, PR, community and more.
However, learning by a major technology company that is in dire need for cash in order to survive, looks like buying your user is not a scalable model.
If a users costs you 100$ to acquire, and then spends 10$ every month, but leaves you at the end of the year, your margins are too small to grow on.
That specific company has millions of paying users, but is bleeding money.
Perhaps real life human community management might be cheaper in the long run than 'buying' your users, or maybe you can try and get a different income than just your subscription service. If you have millions of users, that might just be possible.

Java, c# and the Object Oriented problem.

Oh, god.

I've recently gone over quite a few lines of code written in Java and C#, and found that most programmers have the tendency to over design their applications when using these languages.

A simple Java process that needs to read a file, process it and insert to a database had hundreds of redundant lines of code and objects, a lot of parameters, most of them never in use, and object hierarchy with no purpose whatsoever.
Another C# server was using a useless 5 layer model, most layers just transport data from one layer to another.

My conclusion is this: Either programmers want to demonstrate their knowledge of language abilities no matter the cause, or they're thinking too much about architecture and future possible features, and less about actual functionality.

Some tips that would save you some time and simplify your design:

- Read before writing your code. Almost every problem was already solved, and most of the solutions have already been published online. Stack Overflow already has great answers to ~90% of my questions. The rest I code myself.

- Configuration parameters that don't get changed should not remain in configuration. Some applications have two files - 'customer' configuration and 'application internal' configuration (Known only to tier 3 and up). Then consider moving the 'customer' configuration to a database.

- 20, 200, 2000, 20000: When coding enterprise applications (Big servers, probes, whatever), you should always imagine how much code customisation you need for 20 clients, 200, 2000 and then 20000, etc.: Pick the number you think you'll have in the next year. Your application should support the next level. (i.e. - If you think you'll support 20 customers this year, code as if you'll have 200 to support)

- If all your methods (Not members) are overridden, you should not use inheritance. Use a data member inside your objects instead.

- On the other hand, if all that differ between 10 objects is one function with 3 lines of code, one object with a switch or a decorator pattern might be more effective and easy to understand.

- If a layer in your application is just for communication between two layers, remove it.

- Java has lots of libraries. Do not use all of them. Try to find focused ones that fit your need, and not load the whole jboss stack just for a logger. Remember that class loaders eat up a lot of memory.

- Keep your eye on the target. Be lean. I would rather debug and fix a small amount of code which does its purpose than try to dig in a huge pile of code which does the same.

- Long functions are death. If a function contains more than 200 lines of code, split it to 4 functions.

- Throw your commented code to the trash. No one needs it. This is why they invented source control.

- Get a friend to code review you. Let him be the pilot during the review. If you find yourself explaining too much during the review, you've over designed your code...


And finally, something positive: In this post, one of my most popular, I wrote about the untapped computer power. Yesterday Slicify commented on the post: They've done EXACTLY that - And it looks very promising. Good luck guys!

An over designed Lego car wash

The essential startup toolkit

Not too long ago, software development was an expensive deal.

Development tools used to cost a lot of money, project management and documentation tools cost money, servers cost money, internal network, telephony, office space etc. etc.

Software development practices, on the other hand, aren't that different - Technology is, but the product cycle is largely the same - scrum and agile like methods exist for 20 years now, they were just called micro management :)

I remember coding in Borland C or early versions of Visual C++ (There was no visual studio back then, just a collection of MS tools), writing documentation in Word, updating my Project file, and using a shared network Novell drive. My computer was running windows 3.11, which was considered the standard OS. And none of that was free.

And that was only money. Setting up your business took time. Buying software (At a store...) gave you a lot of discs. Configuring a company network required a specialist. Installations took forever .(Remember disc 3 out of 14?)

Now all you need to have is a computer. It can run a free version of Linux. And if you don't compile, in could also be a cheap Chromebook. Hell, even if you DO compile, there are SAAS platforms which do that as well.

Servers? Basic SSD hosting would cost you ~60$ per year. Monthly internet access + Router + Cell phone would cost ~50-100$ Monthly. Need linux servers? Get a Pi for 25$. Need a phone to test? Use your own :). The only hardware that's relatively expensive would be if you want to develop iOS app, that would set you a minimum of 600$ for a mac mini and 230$ for an iPod touch... (Plus a 99$ yearly developer subscription...)

And all the rest is free. From task management to development tools to server software and source control, everything is completely free (To a certain scale, of course).

The only thing that's really expensive?
Your time.

Now go and make the most of it!

JVM... Don't call it a comeback!

After being away from compiled languages for a while, I've been consulting for a company which uses Java for development.

First time in a while (Forgoing my Android apps, which are too plain to call 'real' java programming), and I must admin I find going back to the code/ compile/ deploy/ test cycle quite tedious - Scripting languages have made me quite impatient :)

Setting up a development environment is hard. The specific startup had no 'real' development and deployment environment, and being an 'ant' fan I created my own setup (maven got me too confused), so I could work.

The advantages, though, are obvious - You make less spelling mistakes. You can use inheritance (Important for some solutions). And because it's a 'device mode' program (Rather than most of my recent work, which is GUI related and needs a touch...), you can actually automate unit tests!

And now for the question - Is there a need today for high level VM type compiled language? (Like C# or Java)? The same programming that I'm doing now could be done with php, or even node.js? (By writing a simple bridge between node and the c libraries...)

I'm actually not sure by now. It's possible that the next generation of programmers would never know what compilation means.

Thoughts about tips for entrepreneurs

Everyone is posting tips for startups, tips for entrepreneurs, tips for your business, tips for how to sell your company, tips for how to wake up in the morning.
Hosting meetups, conventions, non-conventions, garage meetings, beer meetings.
Talking and talking and talking.
Writing "The best advice I've got so far is" articles.
Posting and reposting.

I read a lot of these. Some of them are very nicely written, some of them are obvious and corny.
Seems like a lot of these people forget they were also a bit lucky to get where they are.

My thought - Reading is great, just don't forget to believe in yourself as well.
Don't try to be what you're not. If you're not the no. 1 type, don't force yourself to be the CEO.
If you're not the sales person, don't try to behave like one - Try to sell things the way YOU would, and convince people your way.
And if it doesn't work - Find someone for your team who can do that. In a well balanced team, members complete each other, not just complement themselves.

There's no such thing as a lucky strike.

A while ago, I was managing a large beta project for a large enterprise company. While preparing a thorough integration test plan, I've began to see my document page count rise and rise.
Consulting with my boss about the possibility to repeat this plan week after week with QA (As most of it was GUI, automation wasn't that possible back then), she told me a very smart thing:

- "If it wasn't tested, assume it's not working".

Simply put, whenever posting code to a production environment, even the slightest of changes, test it. See it with your own eyes.
Especially if we're talking about a startup environment, where everything should be as quick and there's no QA - Be extra careful. If you've posted your code without testing and it worked once, you're lucky.
But luck won't hold up forever, and your users will suffer.

Take a couple more minutes and a deep breath and test it.

Most cases, you'll be glad you did.

Performance - Where it counts.

A good report does magic with large data.
It is supposed to take millions of records, and summarise them into a visual entity that transforms into something meaningful for the user.

Recently, in one of my sessions, a client wanted me to focus on improving performance for a specific report in his system.
Report was taking 5 minutes to generate, clogged the system's database, and was comprised of one of the largest SQL statements I've seen in my life.
Instead of starting to spend hours and hours trying to optimise and dig deep, something that would cost my client a lot of money, I asked him a simple question:

- Who produces this report, and how often does it happen?

Turns out it was a weekly (Even monthly in some customers) report, printed and handed out to a manager.
Assigning a periodic process running on a backup database, and automatically sending the result via mail to the manager saved a lot of money and headache to my client.

Performance is important, but you should always focus on improving it where it makes a real difference.

Do it where it counts!

Ride the whale...

Reaching critical mass is crucial for every internet, service oriented or app based startup.
This is even harder when you're an anonymous, bootstrapped startup (Like us at InsideMy.co:)), without much budget for marketing but your precious time and some change for your servers.

So how DO you reach critical mass?

One way is to tediously knock on doors. Keep on the momentum, send more mails, gather clients one by one, and hopefully you'll have enough so the business starts 'driving' itself.

The other way would be cooperating with someone big that can carry you. If you can help their customers and convince their gain from you, as well as quantify it (How much traffic they will gain, money, more customers etc.), you might be in for a nice ride.
This also requires knocking on doors, and some careful management - Especially since if your idea is good, it might just get stolen.

The most important rule - Believe in yourself, and your product, but if you want to 'ride the whale', concentrate on what him and his customers gain.

That might save you a lot of door to door sales.

Whale

Momentum

A programmer's job is creating code.
This means that if you're a coder, you need to sit down and write code. Sometimes, a lot of code - But that's ok - Best coding sessions I've had were not only hard work, but a flow of creativity that you don't want to interrupt. (By the way - The same rules may apply for preparing a long document or a presentation)

When writing a new module (Or even server), the hardest thing, after the whole tedious buildup (Ideation and design processes, which could take months, especially if you've got other code to maintain), would be actually sitting down and writing the code!

I find that the tallest barrier is usually getting yourself to the position where you've got 'something to see'.

This means that setting up the environment, deployment, build and server settings should be taken care of, so you can finally sit down and get into the groove - Do it as fast as you can.

Once in there, I find the skeleton coding approach the most effective to get the momentum I need, especially since it's the fastest way I can see the program come to live. In general, once you've got one flow nailed down, the others follow quite easily.

So get your headphones on, turn your phone off, and get coding!