Another Reason To Launch Your Start-Up Now: Inflation
Comments(0)They say a recession is a good time to launch a startup. It seems a bit counter-intuitive at first, but on second thoughts it makes sense. For one, economic downturns don’t last forever, so by the time things pick up the startup will hopefully be off the ground and be ready to reap in the rewards of the better times ahead. Also historically, new paradigms in technology have been introduced during downturns - think Web 2.0 and the 2001-2003 malaise. Melissa Chang at The Industry Standard lists 5 great reasons why recessions are a good time to start a company.
Naturally, making it so that your venture makes it through the rough times and lasts until the going gets better is crucial. This is where inflation can throw a big monkey wrench in your startup’s financial planning.
When a startup launches with a pool of funds, right off the gate the funds are good for, say X months. Then inflation roars along, forcing that estimate to go down to X-1, X-2 months, etc. And inflation has been roaring along: it recently inched to a 17-year high in the US, an all-time record in the EU and Canada, and emerging economies like China and India have been breaking records of their own (here and here).
So if you have an idea and some money set aside, either from saving or pledges from friends and relatives, launch that startup and launch it now. Don’t wait, because in a few months from now that amount of money may not get you as far as it would today.
The extent to which the current inflationary environment affects different startups can vary. Launching a software-based startup can be done on a shoestring these days with the relatively inexpensive cost of hosting, basic hardware and various startup support services (like SimpleDB, EC2) etc.
The relatively low “price of entry” for a software startup shouldn’t cause complacency to the threat of inflation though. Often times the largest expense category of startups, especially smaller ones and micro ISVs, is the cost of living of the founding members, some outsourced work here and there (e.g. graphic design) and maybe some travel (maybe a bit more travel if you are launching an enterprise software startup, actually). Unfortunately the expenses associated with these categories have been rising much faster than many other items that the official inflation figure tracks.
Don’t expect much of a break when it comes to hiring help either - tech workers are still in high demand, their salaries in emerging economies like India have been catching up as this story from Bangalore indicates and even reputedly not-so-great economies like Germany have now an official shortage of engineers.
There is little sign of inflationary pressures dissipating any time soon. If anything, they might only get worse. Inflation-stoking events are everywhere, from government-sponsored bailouts of bankrupt institutions (Northern Rock in the UK, Bear Stearns in the US) to economy ’stimulus’ packages (e.g. the one in Spain), from Central Banks worldwide pumping ‘liquidity’ into markets and keeping interest rates below inflation rates.
For example, in the US the Federal Reserve rate is 2.00% or 2.25% through its discount window. These rates are available for select privileged institutions (i.e. not you and me). With inflation officially at 5% and unofficially much higher, these select privileged institutions that get access to this sweet deal are effectively being *paid* to take the money. And thus money is created out of nothing and down the inflationary spiral we go.
A surprisingly large number of developed and developing countries in the world have their Central Bank rates close to or below inflation, so the difference here is mostly about the *extent* of the creative ways in which new money is pumped into the system.
The official response on inflation so far has been mostly “yeah, it’s bad, we know it, we are just gonna look at it some more and hope it goes away on its own. Hey, how ’bout another multi-billion dollar bailout?”.
Now, I am not an economist and maybe this is the correct course of action given the circumstances. What I do know though is that things are unlikely to change in the upcoming few months while my startup ramps up, and I am planning accordingly.
Inflation is real, inflation is here and ignoring it can be detrimental to the health of your startup, present or future. Plan now, act now.
BlackBerry vs. iPhone: What If There Is No Winner?
There has been a lot of excitement in the mobile space lately. The release of the 3G iPhone has made many mark July 11th on their calendars and got many an Apple fan buzzing. BlackBerry is making headlines too with the upcoming BlackBerry Bold. And of course not to be forgotten are the ‘Google phones’, the release of which is said to be on target though likely to arrive a bit later than previously rumoured.
All this has got people wondering who will be the winner in the mobile space. Is Apple going to dominate the space with the slick iPhone design and even slicker marketing, or is the headstart enjoyed by BlackBerry devices combined with their strong grip on the enterprise market enough for them to clinch the top spot? Or could Google come out of left field with whatever it is going to come out of left field with and crush both RIM and Apple into oblivion?
But lets pause here for a second and ask ourselves, what if there is no clear winner at the end of the day? In other words, what if the smartphone market is simply not a winner-take-all industry?
For one, customer needs in the space may be too diverse for a single player to successfully satisfy them all. Early signs are starting to develop that this might be the case. Both the iPhone and the BlackBerry have successfully captured a core market, and users in either ‘core’ have little reason to switch at present. The 300-emails-a-day corporate user who wants mobile access to his company’s CRM system will probably continue being a BlackBerry customer, and the cool kid with voracious appetite for web content and YouTube videos will likely stick to his iPhone. When I was thinking of which platform to launch my startup on, BlackBerry was the natural choice just because my app requires certain amount of typing and BlackBerries are considered to be more typing-friendly.
Another argument against the winner-take-all scenario is that the smartphone market may be growing too fast for any single company to be able to successfully dominate. BlackBerries are selling at a blistering rate: Research in Motion sold 9.4mln devices so far in FY 2008 compared with 4.4mln in the same period FY 2007 for an annualized growth rate of 114% (link to quarterly financial statement here). And judging from all the excitement around the 3G iPhone, it will probably sell many millions in less the time it takes to say “I’ll have the chicken, please”. Over at Sprint, the new Samsung Instinct touchscreen smartphones are flying off the shelves like crazy too.
Dominating an industry that is growing at a break-neck speed may be tough to achieve, even for great companies like RIM and Apple.
So the BlackBerry is popular in the segment that it targets, and the iPhone is popular in the segment that it targets. In fact, it is easy to imagine a few more segments developing in the smartphone space over the next little while as the industry expands and evolves. This will give the opportunity for new players to step in and make a lasting impression or for the existing ones to capture more market share.
Here are a few segments that will likely develop:
1.The smart phone under $50 (but without a plan). Smart phones are currently too pricey for mass adoption, especially in emerging markets. Fifty dollars sounds on the low side these days, but just like a lot of other things in technology, if it looks impossible now, just give it a couple of years. Intel is already stacking its chips accordingly and making a heavy investment in a super-small and cheap mobile processors. Nokia has done well in the lower price points in the cellphone market for years and they are making their move in this space too with the release of the E71 (Boy Genius Report on the E71 here). Price is not there yet, but just give it time, just give it time…
2. The smartphone - extension to the user’s computer(s). The ability for users to have transparent and seamless access to the same information at home or at work as they have on their mobile devices without having to initiate some sort of a manual sync would be killer feature. And the rapid emergence of clouds can be a major catalyst here - mobile syncs to cloud, cloud syncs to PC, etc. MobileMe looks like the first crack at this, but at $99/year it will likely not be massively adopted overnight.
Humm, can anyone think of a large company with massive cloud infrastructure and growing mobile aspirations?
Honorable mentions in this category here goes to Windows Mobile devices for enabling users to view their MS Office files on the go. While viewing spreadsheets on your mobile device may not overly excite many, Microsoft has recently unveiled their Mesh project, which aims to give users the ability to sync files across devices. Could it be that MS Mesh evolves into a MobileMe for the enterprise?
3. The app phone. No, it ain’t going to be the iPhone. A large amount of software is bought by companies and they are going to choke at Steve Job’s 30% cut. Do you see Microsoft giving 30% to Apple for each download of Word Mobile? I don’t think so either.
The BlackBerry’s platform is developer-friendly (kind of), but the absence of an App Marketplace is a set-back. The title in this category is pretty much out for grabs. A glimpse of an Android demo showed an icon labeled “Market” which got people speculating.
Oh it looks like it is going to be an interesting year in the mobile space!
The Future of Enterprise Software: I Am So Scared, I Am So Excited
It is not very often that one gets to hear about events that can dramatically change an industry. And yet there it is, right in front of us in the form of a lawsuit filed by Waste Management against super-large software vendor SAP. The lawsuit allegedly exposes some of the ugliest and most dishonest practices in enterprise software sales and the court’s reaction to it has the potential to dramatically transform the industry as we know it.
Basically Waste Management spent $100mln on a system that it claims was of little use after delivery. But instead of just swallowing it like many other purchasers of ill-fated software products, they decided to sue. And sue big.
The court materials are actually a pretty interesting read. In it, Waste Management alleges that the software it bought from SAP was “utterly incapable of running the operations of an American waste and recycling company” despite SAP presenting it is “out-of-the-box,”, “integrated end-to-end solution”. Another quote from the court materials that I found intriguing:
As part of its fraud, SAP presented Waste Management with a series of pre-contract product demonstrations consisting of what SAP represented was the actual Waste and Recycling Software. Yet Waste Management has discovered - and, in internal documents, SAP has admitted - that the pre-contract demonstrations were in fact nothing more than fake, mock-up simulations that did not use the software ultimately licensed to Waste Management
The full text for the court filing can be found here. Now, I Am Not A Lawyer and am the last one to know which direction this lawsuit will go. Moreover, this is the story from Waste Management side only and I am sure SAP has something to say as well.
However, the implications of this lawsuit and the attention it drew can be profound and go much further than toxic publicity for SAP. Rest assured, the business community at large is taking note of these developments. If the courts rule in favour of Waste Management in any of the counts, the salesmen at your enterprise software company might be in for a completely different experience next time they try to make a sale. Maybe at the next product demo given to a customer, instead of just people from IT and the potential users there will be also a couple of people from the legal team in the audience. Oh, and the microphone is on ‘record’, by the way. And how much of this demo is fake anyways?
Whichever way you look at it, the implications for the reputation of the large software vendors are not positive. Popular articles like this don’t help either. And all this is happening while in a report by William Snyder from Gartner comes out basically saying that enterprise software licensing model is in for a radical change (original can be purchased from here, discussion of the report can be found here) . One of his reasons? The existing sales and licensing models just won’t fly in the emerging markets.
It looks to me like the big enterprise software vendors may be headed for a period of soul searching over the next few years as their sales and licensing models become increasingly under scrutiny and more and more customers balk at the existing practices. The good ole days of fat profit margins may be coming to an end, a sentiment echoed by Snyder as well.
But in every crisis there is opportunity, and there are plenty of opportunities in this one. The opportunities are there for enterprise software companies that maintain good, healthy relationships with their clients and don’t turn their potential users into irate and vociferous litigators. And the opportunities are there for companies that invest the time and effort on building new products and technologies that innovatively solve customer’s problems instead of relying on sales prowess alone. Given the potential PR damage and legal costs from this highly public lawsuit, I wonder if SAP now wishes they had spent more R&D time and effort on designing and implementing software that better meets their customer’s expectations.
More so than ever, the time is coming for companies that build it right and do it right to prosper while the ones that exclusively focus on just selling it right and who-cares-what-happens-after-the-deal-closes to stare at a lacklustre or flat revenue curve. Because you really can’t fool all the people all the time.
Dependency Injection in JBoss 4.2: Hold Your Excitement
For the last little while I have been pushing my company to migrate our Enterprise Beans to EJB3 (most of our beans are of the 2.1 variety) and Dependency Injection (DI) has been one of the EJB3 features that I have been very excited to see getting used throughout our middle tier.
DI is a great new addition to the EJB spec which gives the ability to ‘inject’ an EJB reference in another bean simply by using the @EJB annotation:
@EJB
MyBeanInterface myBeanReference;
At run-time, the container populates the field with the appropriate bean reference, thus saving the developer some manual JNDI lookup code. For a more thorough discussion of DI, check out Debu Panda’s article.
The biggest selling point for us was that EJB references can also be injected with a bean setter methods, e.g.
@EJB
void setMyBean(MyBeanInterface myBean){
this.myBean = myBean;
}
which can make a bean easily unit-testable with the setter used to pass in a mock object during the test set up.
However when we started using DI with the latest stable version of JBoss (4.2.2) we found that DI of EJB references has limited support. Namely it is only supported for objects inside the EJB container. This means that while beans can refer to each other with the @EJB annotation, other managed objects like servlets and non-EJB web services must still use JNDI lookup to access any Enterprise Beans.
To quote from the JBoss docs:
“JBoss Application Server 4.2.2 implemented EJB3 functionality by way of an EJB MBean container running as a plugin in the JBoss Application Server. This had certain implications for application development. The EJB3 plugin injects references to an EntityManager and @EJB references from one EJB object to another. However this support is limited to the EJB3 MBean and the JAR files it manages. Any JAR files which are loaded from a WAR (such as Servlets, JSF backing beans, and so forth) do not undergo this processing”
So even though the JEE 5 specification stipulates a wider scope of the @EJB annotation, JBoss 4.2.2 doesn’t support it. In fact JBoss 4.2.2 is a ‘bridge’ version that doesn’t claim full JEE 5 compliance. And while I am grateful for the many other JEE 5 features JBoss currently does provide, I hope this post saves people out there the time and effort of trying in vain to make @EJB references work for servlets, web services or other WAR components.
Why I love working in an Extreme Programming Environment
A lot has been said about how Extreme Programming is great, how it produces better and more flexible software, fosters a positive development environment, increases productivity, agility, code quality and so on and so forth.
Well, this post is about none of that. I just want to share some personal (and probably highly subjective) reasons why I have really enjoyed working in XP environment. My focus is more on the person (the developer) as opposed to the final product although the two often go hand in hand - I am yet to meet a developer who takes pride in producing crappy software. Really, I haven’t.
I have been working for an XP shop for a bit more than 2 years now, and the comparison that I am drawing is against a past life of working for a large multinational software vendor with an R&D team well into the thousands. It has been quite the contrast let me tell you that!
Here are some of the reasons why I love working in an XP environment:
Calling a stateful Web Service with JBossWS
Although Web Services are usually described as stateless and involving distributed applications exchanging one-off messages here and there, stateful web services are not that uncommon. I recently spent some time trying to invoke a stateful .Net service from JBoss (using JBossWS) and I thought I’d post the code for that here.
The .Net service required login before further methods on it are invoked. This scenario is probably quite common out there as more and more 3rd party server-side components that require authentication get exposed as web services. A web service can be made stateful by using the SOAP header to stuff state information or by setting cookies in the HTTP session. The web service I was invoking used cookies, so I will talk about that here.
The following enables cookie support on the the web service client side:
Service service = Service.create(wsdlURL, serviceQName);
ServiceInterface proxy = (ServiceInterface)service.getPort(ServiceInterface.class);
((BindingProvider)proxy).getRequestContext().put( BindingProvider.SESSION_MAINTAIN_PROPERTY, true);
However, doing this in itself IS NOT ENOUGH! Because of a bug in JBossWS, only versions of JBossWS 2.0.1 and newer have the above working correctly. JBossWS 2.0.1 was released fairly recently - the release date is listed as 17 Aug 2007. JBossWS comes with JBoss, however it is only since JBoss 4.2.2 GA that JBossWS 2.0.1 is included (older versions of JBoss have JBossWS 1.x instead).
Basically to make the above work you will need the latest versions of JBossWS or JBoss (as of the time of this writing) because versions from as recently as a few months ago won’t work.
Links of the day
How Bad Is Your Architecture? Measure it the Agile Way!
It happens to developers all the time. After working on some piece of code for a while, they discover how truly inflexible, counter-intuitive and generally not helpful its architecture really is. Only miracles and truly brilliant developer insight is capable of making new features happen, and just barely so. Fixing bugs feels like a whack-a-mole, and only wonder-coder Joe who has been with the company for 6 years knows how things really work down there.
But then management is not always excited to pursue larger architectural overhauls just because developers say so. Hey, that piece of code has been working just fine over the last 8 years, so why touch it now? And anyways, why on earth should we be spending time on something old that delivers no visible value instead of working on all these new features that we promised to deliver to our customers??
If re-architecting that piece of code requires well above the regular 2-3 day refactoring job and would likely go on for weeks, a developer may need arguments that go beyond the “but it would be so much nicer if…” to convince everyone that more work needs to be invested there.
For the remainder of this post I want to present a practical way of measuring the drag factor of suboptimal architecture. We recently came up with it in my company and are in the process of making it work for us. The focus is on larger architectural issues, usually ones that a routine refactoring is not enough to fix. Although the discussion is in the context of Extreme Programming, it can easily be extended to non-agile environments given the right team dynamics.
The main idea is fairly simple. Upon completion of every story in the XP iteration, an estimate is given to reflect how much the story was “slowed down” by the presence of “bad” or suboptimal architecture. We call this the Legacy Architecture Cost (LAC). If more than one component or area of the product is suspect of needing re-architecting, the LAC is broken down by area/component. After a certain period of time, say 6 months, the LAC total for each component or area is added and analyzed on a Return on Investment (ROI) basis.
For example, if it turns out that over 6 months the team has spent 20 man days because of the suboptimal design of some crusty component that would have taken 10 days to re-architect, that component is an obvious candidate for redesign. However, if the LAC for another component is 5 days and it would have taken more than a month to fix, maybe we shouldn’t roll up our sleeves just yet.
A natural priority list then emerges. Components with the highest ratio of LAC to estimated fix time percolate to the top of the list of thnigs that need to be re-architected first. Of course, the usefulness of the priority list depends on the length of the LAC collection period as well as on how statistically representative it is of the overall software development activity in the team.
Just blindly using the LAC ratio would probably be over-zealous too. Other things can influence the decision of what components to re-architect first, such as current priorities as well as expectation of upcoming work (e.g. are the next few months going to be mostly backend work?).
The idea is to give some empirical and objective value to the drag factor of suboptimal architecture and move the re-design discussion into less subjective territory.
I will make more posts as we continue to use this technique. This is all work in progress for us, so any feedback or tips are highly appreciated!
Related links:
Why Certification was useful for me
The topic of developer certification has stirred a lot of debate recently. Is it good, is it bad, is it just downright evil? Raganwald recently jumped ship on the certification debate with his Certification? Bring it On!. An excellent rebuttal over at Enfranchised Mind was quick to follow and made some excellent points as well.
But I as a developer found certification useful for reasons somewhat different than what these guys are talking about. Certification worked well for me because going through the actual process (I did the Sun Certified Java Programmer about a year ago) made me brush up on areas of the Java platform that, for one reason or another, I hadn’t had much exposure to in my professional life up until that point.
The companies that I have worked for in the past few years are pretty established and by the time I joined them, certain parts of their code base like handling times, formatting dates, threading or doing I/O etc. were pretty mature, stable and bug-free and had been so for a long time. Not much work was needed there. So after a couple of years of Java development out in the industry I found myself not completely satisfied with my knowledge in some of those areas.
Going through the certification process not only gave me a structured and focused way of covering areas that my professional experience didn’t touch on or just touched on fairly lightly. It was also a good segway (or an excuse for a segway) into digging out more information on some of the topics that the certification book just mentioned but didn’t elaborate to the extent that I would have liked.
Was there sufficient material on these topics in the SCJP to achieve what I personally would consider reasonable proficiency? Sometimes yes, sometimes not. Certain topics like generics are covered in a much more enlightened way in articles like Gilad Braha’s Generics in the Java Programming Language than they are treated in the SCJP. But hey, the certification curriculum was a good starting point.
Now, is getting certified the only way to brush up those “dusty corners”? Absolutely not. Developers can achieve the same result in a myriad of other ways without having to pay the $200 for taking the exam (shame on you Sun for upping the fees again!). Do an interesting project on the side, launch a cool site or just regularly scan the various posts on dzone. There is plenty of good stuff out there to keep you well-informed and your skill set current.
Certification is just something that worked for me. And if you are a junior to intermediate developer, it may work for you for the same reasons, especially if you work in larger company where the projects last for many months and responsibilities usually cover a small part of the end product and require skills that mostly fall in a narrow subset of the languages/technologies used.
