This blog has moved

This blog is now located at http://igorroyzis.blogspot.com/.
You will be automatically redirected in 30 seconds, or you may click here.

For feed subscribers, please update your feed subscriptions to
http://igorroyzis.blogspot.com/feeds/posts/default.

When are we really ready to move software to production?

First simple/obvious stuff - code has to be bug free. What this means is that after a thorough QA and UAT process there shouldn't be any known bugs left. There might and probably will be some minor unknown bugs, but that's just the way it is.

Now, when it comes to the functionality, it's no longer "it works" or "it doesn't work". It's the opinion of the stakeholders. The more stakeholders, the more opinions. As technologists we'd like to say that we implemented all the functionality specified in the initial requirements. And that might be true, but there were numerous "drive-by's" by stakeholders with new requirements. The project maybe took 6 months and along the way market conditions might have changed. So by the time developers think they have completed the project, stakeholders want to change and add a bunch of features to improve the final product.

The risk here is you can "miss the boat" if you try to deliver a perfect product on the first pass. Think of all the solutions you use on a regular basis. Microsoft Office Products, Social and professional networking websites, Online banking, etc. Were they perfect day one? Of course not, but they had enough important features for you to start using them. Over time, new features and improved functionalities were added and these products matured and became even better.

Just use a Pareto principle (the 80/20 rule) when in doubt.

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.