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!