Self funded startups vs. established businesses - challenges and advantages

Startups have limited technology assets. Their goal is to implement an idea, whether it's product or service, in a shortest amount of time, with limited resources and minimal budget. Decisions are made quickly, no red tape, everyone works towards a common, short term goal and understands the risks of working in a startup environment.

Established, large businesses, have variety of existing technology assets. Their goal is to have better exposure in the market, better service their customers and continuously (usually slowly) enhance existing product or service offerings. Decisions are made slowly, lots of red tape, people just do their job and usually take employment for granted (though it varies depending on economic and market conditions).

Ok, maybe I am simplifying it a bit, but overall, above statements are accurate representations of my experience with startups and large companies.

Technology departments in startups are either very small or non-existent. In a technology startup, one of the founders is usually someone with technical background. He tends to be hands-on and does as much as possible on his own before hiring other technologists. The times of "show me the business plan and I'll invest 5 million dollars" have long gone. "On a shoestring" is the new era. Hiring cheap labor and discovering that they did not produce expected results in 3 months is usually fatal for a startup (large companies do this all the time). Startup companies have to be agile. For things to get done fast and right, startups must only deal with technologists who possess niche expertise and have solid experience developing similar solutions. It is not unusual to have a team of "star developers" in a startup. Technology team in a startup never idles. Developers often work 12 hour days for several months in a row. The possible rewards are obvious. If startup is successful, everyone gets to be a part of this success, both professionally and financially, especially the first 10 or so employees. People feel proud of their accomplishments. Initial team may (and should) get stock options or some kind of profit-sharing to be driven and feeling more than just another employee. On the other hand, it is also not unusual for a startup to disappear before it reaches its 2 year anniversary. Startups are usually for people with riskier, entrepreneurial personalities.

In contrast to startups, established businesses have large IT departments, including developers, web designers, system administrators, database administrators, etc. It is rare to see large it departments with all "star developers". There are multiple projects going on at the same time. Workload usually comes and goes. One day you work 10 hours without a coffee break, another day you have very little to do and you're cruising the web (hopefully learning something new about software development related subjects). Multiple layers of management create roadblocks for producing quality software, on time and within budget. Agility is usually not a part of large company vocabulary. Politics is a way of life, even for techies. It usually takes much more time and money to develop the same functionality in a large company then in a startup. Rewards are expected in the form of salary, benefits and possible bonuses. Large companies are for those who prefer to settle into a comfortable, "long term" job with pre-established processes and organization.

Some developers are happy working in startups, while most prefer large companies because of a false sense of security and stability. Though history shows that size of the company sometimes doesn't matter, especially in today's market.

25 ingredients for Internet startup success on a shoestring budget

While being a part of several startups over the years, both someone else's and my own, I learned, sometimes the hard way, that one can't hack through a startup/development phase and hope to succeed just because he has a great business idea. Following are the "25 ingredients for Internet startup success on a shoestring budget" from a hands-on CTO perspective (that is me).

1. A technology startup must have both, business domain expert and hands-on technology expert as partners/founders. Could be the same person (though a rare occasion).
2. You must create a business plan. It is not true that business plans are only required to raise capital. Business planning is the foundation of any business.
3. Create detailed use cases which describe all the features of the system. These don’t have to be formal UML use cases. Plain word document will suffice.
4. Create rough page mockups to describe what content goes in to each web or mobile page. One doesn't have to be a web designer to do this. As a matter of fact, hand drawn sheets of paper can always be scanned as used as mockups.
5. Design overall system architecture. Following has to be considered: (1) architecture has to work with minimal set of simplest technologies to get the job done; (2) architecture has to be broken into independent layers, services and components which can be developed independently by different developers. This can be achieved by well defined API (Application Programming Interface); (3) architecture has to account for growth.
6. Create development project plan broken into phases of 1 to 2 months each. Target no more than 6 months for the whole project. Break into multiple projects (deliverables) if the project spills over 6 months, but make sure that most of the core business functionality gets into the first deliverable.
7. Post web/graphics design portion of the project on elance. A sophisticated web site can be designed by a professional offshore design firm for just $1000 to $5000 depending on complexity. This is 5 to10 times less than hiring a local firm. The result is a set of all web pages, templates and graphics for the project.
8. Post development (coding) portions of the project on rentacoder.com or elance.com. Make sure to break the project into smaller, independent chunks. This can only be achieved by right architecture for the whole system (described above). This will allow to hire multiple developers to work in parallel as well as minimize (or even eliminate) risks of jeopardizing intellectual property (the source code).
9. Setup a dedicated test/development server with a reputable hosting facility. These may cost $80 to $120 per month for a well configured Linux or Windows server which will serve as a test platform, development integration platform, and source code repository.
10. Source code repository must be configured with limited access based on developer role. One developer should never see all the source code. He should only be able to work on his portion of the system.
11. Review web design and programmer project bids, review portfolios and work samples, hire designers and programmers. This is where the bulk of the "shoestring budget" will be spent. And it's going to be at least 3 to 4 times less then hiring local contractors. This is where having a hands-on partner/CTO is a must, because once the system is built, CTO should be able to maintain it. Once revenues start coming in, CTO can hire local developers, train them and let them maintain and improve the system.
12. Review web designers' work on a daily basis. Make sure they reply within 24 hours to every question/request (they should agree to this before you hire them).
13. Developers must provide high level design and estimates for each assigned task before they start any coding.
14. Developers must commit code daily to source code repository. It must not break any other code and it must have unit tests for each granular piece of functionality.
15. Deploy functional features to test server weekly so that the code is integrated and latest functionality can be reviewed and tested.
16. Review committed code weekly and make developers correct anything that doesn't pass the "review".
17. Developers must email a quick daily status update.
18. Developers must email a detailed weekly status report which includes tasks completed, in-progress and any issues.
19. Setup hourly continuous integration of committed code with automated failure notification via email.
20. Conduct 1 to 2 weeks of thorough testing on test server after each 1 to 2 month long phase. Basically, allocate 25% of total time to testing and debugging.
21. Make a list of friends and family for initial test drive and feedback.
22. Flip a switch on for friends and family and let them use the system for up to 1 month. Ask them to fill out a feedback form.
23. Perform minor refactoring based on friends-and-family feedback.
24. Roll out the system for public use.
25. Announce to the world via LinkedIn, Facebook, Twitter, MySpace or whatever other social and professional networks are frequented by your intended audience.

I intentionally omitted all the business development, marketing and financial related ingredients. They deserve a separate article.

JavaOne 2009

It’s been 11 years since my last visit to JavaOne 1998 conference in San Francisco. I was starting with Java, I was young and eager to learn anything and everything in order to be a more successful Java developer. Here I am again, at JavaOne 2009. Well, not much changed (except for the young part). I am still trying to learn as much as I can to see what others are doing in order to make my team a better development team and to make sure that my architectural and other technical decisions are not just based on my experience but on experiences of other technology executives and architects alike.

4 days were filled with very informative technical sessions, meeting other technologists from all over the world, learning about new and important developments and enjoying a great developer atmosphere in a great city.

There were a few hundred sessions so I had to choose carefully. I was able to fit 5 to 6 sessions per day. I was primarily interested in learning more about developments in the areas of mobile, web 2.0, performance, frameworks and architecture.

Here is a quick synopsis of what I’ve heard and seen a lot:

• JavaFX will be replacing Java AWT and Swing and possibly even Java ME. Sun and soon Oracle are really pushing JavaFX forward.

• OpenSocial and Facebook api are becoming more and more popular for developing and accessing social web applications.

• Spring Framework is getting better and better. Version 3.0 looks very promising.

• Forget about stateful web applications. IF you want flexibility and scalability look seriously into using REST.

• We all knew it but it’s worth repeating – architecture must be as simple as possible and as flexible as possible.

• Asynchronous event processing is probably the most important aspect of system performance and scalability.

• I was surprised to see by my estimate almost half of attendees who brought their laptops to sessions used MacBooks.

• James Gosling is still going strong and moving Java forward.

If you’ve never been to JavaOne try it next year. It’s a wonderful experience.

Today’s IT Executive

By the time a programmer grows through the ranks and becomes a CTO he is no longer able to write good code, discuss detailed technical issues with developers and architects and determine whether his developers are bull…ing him regarding the estimated effort to complete projects.

Why do most CFOs know everything there is to know about financials of the company and can communicate well with accounts payable or receivable clerks? Why do most Advertising Executives know everything there is is to know about advertising? One can’t become a CFO after being a technologist for 20 years. On the other hand, I’ve seen accountants and other business people become IT Executives. I sometimes wonder what would happen to the Romans or Vikings if their leaders were not some of the best warriors. Those leaders would quickly loose respect from their troops (that is if anyone survives after losing the battle).

The point I am trying to make is that in order to be a good IT Executive one must always keep himself in “techie” shape by not just reading about latest IT trends, but also participating in architecture and design discussions, looking at the code (or even better writing some code), trying to fix a network problem, download and install desktop and mobile software themselves instead of asking their SA.

I am being asked sometimes why after almost 20 years in IT I still like to roll my sleeves and write some good code. Well, I have 3 reasons:

• I can deliver better solutions by knowing everything there is to know about technologies my teams are working with.

• I feel comfortable discussing and using technologies at any level, whether it is as programmer or enterprise architect and I can’t be fooled with regarding project estimates or things that can or cannot be done.

• I feel secure about my professional life because I always stay sharp and able to jump into battles.
  

Three ways to cut costs in IT

1.      Let’s start with the Pareto principle (usually known as the 80-20 rule), which “states that, for many events, roughly 80% of the effects come from 20% of the causes.” Most software projects take too long because developers spend 80% of their time on developing unnecessary functionality. This usually happens if:

a.      Business leaders request functionality which is of no use or provides very low or no ROI at all.

b.      Software architects/designers try to account for every possible future requirement which makes the solution too complex to develop and maintain.

Solution? Be a minimalist when it comes to creating technology solutions for businesses.

2.      Another popular money wasting trend for IT executives and business leaders is to hire cheap labor in order to cut costs. There is an old saying that “you get what you pay for”. Another one goes something like this: “you buy cheap, you buy twice”. My point (and it has been proven many times) is that trying to hire cheap labor will only bring low quality solutions, take long time and often fail altogether. Hire the best and get good quality on time and within budget. At the end of the day it’ll cost you less.

3.      This one is actually a no-brainer. Why should you pay for a commercial product if there are several open source products of same or better quality available in most cases? From web servers to message oriented middleware, from web frameworks to databases, from CRM solutions to complete ERP systems – open source has it all. Use open source products to save hefty amounts on licensing fees and get top notch quality solutions.  

It’s time to "mobilize"

I remember not so long ago businesses weren’t serious about selling products and services on the Internet. They thought that people wouldn’t actually buy products and services online. Well, those who believed so missed some excellent opportunities and allowed competitors to take a big chunk out of the market.

Here we are, in 2008 and a lot of companies aren’t so serious about selling products and services via mobile phones. Let’s fast forward to 2011. Every phone has built in full internet browser; at least 4 GB built in memory and accessing internet with 3G (or should I say 4G) speeds. Every online retailer offers services and products on mobile phones. LBS or Location Intelligence services provide timely custom information to consumers based on their location. And all of the above is taken for granted the same way as services and products offered on the Internet.

Do you want to be a company that “mobilized” in 2009 and improved their offerings every 6 months to be one of market leaders in the mobile space or a company that realized missed opportunity and started their “mobilizing” efforts in 2011?

What to do when client asks for quick-and-dirty solution?

I made a presentation and a proposal to one of my clients the other day to develop a customized ERP solution for their unique online auction system. This was a 7 page document which included research and comparison of 3 open source ERP products, architecture diagrams and a detailed project plan.

They liked all of it except the total duration of the project, which was 3 months. I was asked if I could do a less than perfect job and deliver a “quick-and-dirty” solution, because their business needs something quickly.

I politely refused.

I could’ve just said “yes, I can do quick-and-dirty”, make quick buck and go on to service other clients. Sounds good right? Wrong! If you’re a consultant or contractor, your reputation depends on quality of your work and on what your former clients say about you.

Say you develop a quick-and-dirty solution. It works for your client for a few weeks and then suddenly it breaks because 10 users tried to use the system at the same time. Who do you think the client is going to scream at and blame? Right, you. Do you think they’ll refer clients to you or say kind words about you and your services?

When it comes to providing services, quality should be of utmost importance to us as consultants. At the end of the day our reputation is more important than a few extra bucks in our pocket.