December 15, 2008
Update 3: Because I got stalked, I change the tilte of the post from “The unit testing lie aka dynamic typing testing lie”. I like this blog, but it’s not worth it. The view that dynamic typing and static are equally safe is based on the assumption that dynamic developers do more unit testing (what the compiler otherwise does) than static developers to ensure safety.
Update 1: Thanks to Graeme. I have been unclear with my post. The lie I’m talking aboutis that there is no problem with dynamic languages or a difference between dynamic languages and static languages concerning type bugs you can write unit test, suggesting that developers really write unit tests to cover type checks. All would be good if people write tests. Josh as someone who fixes Rails projects says that he often sees not enough or no unit tests in the Rails projects they are called to fix. If you use dynamic languages and have >90% test coverage including duck typing, you’re safe and this post does not apply
Update 2: If you want to make a sensible comment, you could say “Lie is an exaggeration, could it be a logic fallacy?” and I would reply “Saying knowingly not the truth is lying”. Or you could say “From the 37 projects in [Dynamic Language Of Your Choice] which I have investigated, the lowest code coverage with unit testing was 80%” and I would reply “Thanks for the facts, seems contrary to the facts in my post unit testing is widespread in dynamic language projects” and change the title. Or you could give your opinion about any topic you wish, attack me and spare me facts.
Stumbling upon one of the very best articles about web programming for some time: Rails Worst Practices: 13 Coding Nightmares You Should Avoid by Josh Symonds. One of the experiences Josh is that developers don’t do - enough - unit testing:
[Testing] This should probably be higher since it’s one of the most annoying things about picking up an existing codebase. A lot of the code we get isn’t well tested, or even tested at all. Untested code is very very difficult to alter: you’re not sure if the small change you’re making will break functionality out in the middle of nowhere, and you have no way of testing it without following through the application flow every time you make a change.
When discussing dynamic vs. static languages, the arguments for not needing static type checks are based on more unit tests.
The blog post says: Nada, developers don’t test. [1]
This reflects my experience. Developers don’t test. They do test after they got a bloody nose several times, best a bug lost some money, lost bookings or orders or the plattform was down. Then developers literally yearn for more security. They write tests if you tell them again and again (or they are very very good). And you need hard coverage metrics and goals - even if it’s 100% (some won’t agree). Otherwise they are over-optimistic, over-confident and always under deadline preasure. Unit tests are hard to explain to business users and managers - they can be explained but often developers do a bad job at explaining them.
I was astonished by the claim that everything is fine in Rails-land and developers, contrary to most of their brethren, do extensive (even more than for static languages) unit testing. Seems to be mostly a myth - especially with more Rails developers as the experience level goes down. You can have a community of 1000 top coders, but not of 100.000 top coders, there aren’t enough.
There is much more interesting insight in the article:
Chubby Controllers Must Die
There should be no business logic in a controller.
It’s not about Rails. Every project and every web framework I’ve seen has been abused by developers. They put code into parts where they should not. In Struts, in JSF, all the time. Developers don’t change and a web framework won’t help. Strict coding practices and reviews help.
NEVER Assume You Don’t Have Nil
Maybe you assume that your ActiveRecord object has an association on it, like address. So you innocently type user.address.telephone and blam! Your application blows up because address was, in fact, nil.
Again the same experience. The biggest problem in Java are Null Pointer Exceptions, people don’t check for null often enough. The don’t use Either style error checking either (ha!). And Java doesn’t support safe dereferencing yet:
Null dereference expressions - Null checks with ‘?’ syntax similar to Groovy… lettign developers avoid a nest of null checks.
Another one from the post:
Check ActiveSupport (and other Rails/Ruby classes) FIRST
I see a ton of methods that already exist in ActiveSupport that are hand-coded from scratch. Stuff like Time#beginning_of_week and pluralize pops right to mind. Also there are a lot of people who do scratch versions of time_ago_in_words and number_to_currency (two of the most helpful ActionView Helpers)
Would easily translate to “Check commons” in Java. Or check the JDK. Especially reuse JDK code when someone asks you this in an interview
All in all, excellent post, go read it.
Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
[1] All generalizations outside of physics, mathematics and chemestry are wrong. Without them one cannot make meaningful descriptions about the world. This should read most developers and “test enough”.
Update:
Because people are not accustomed to the discussion, some entry points into the dynamic vs. static discussion, how static typing is just a kind of test and how unit tests are better than static typing.
About using unit tests to find usual compiler errors by Steve:
But the argument that I’m making is NOT that compilers don’t occasionally help you catch errors. The argument that I’m making is that you’re gonna catch the errors one way or the other. Especially if you’ve got unit tests, or QA or whatever.
About dynamic language users doing more unit tests:
People who use languages with strong static type systems seem to do a lot less unit testing.
In a paragraph about “The strong vs. weak typing issue really gets people worked up.”:
We can achieve sufficient reliability through a combination of rigorous unit testing and agile development practices.
About useful code coverage for Rails by David:
In terms of new features, we’ve been able to add new features to the lift code with fewer defects than with the Rails code. Our Rails code had 70% code coverage. We discovered that anything shy of 95% code coverage with Rails means that type-os turn into runtime failures. We do not have any code coverage metrics for the lift code, but we have seen only 1 defect that’s been checked in in the 2 weeks since we started using lift (vs. an average of 1 defect per checkin with the Rails code.)
About how unit testing helps to find bugs in your code when using Groovy (that otherwise the type system finds):
“It might be scary to do away with all of your static typing and compile time checking at first. [...] You should make all efforts to use unit tests to verify your intended behavior.”
About the importance of unit tests in the Rails community by Eric:
“The Rails framework and the Rails community are both built on a culture of good programming habits.
[...] Unit tests? Built in and highly encouraged.
A variant of the argument about testing, which says: Static typing doesn’t help you much, because it doesn’t verify all behavior, you need unit test nevertheless. Suggesting that people do unit tests, by Bruce:
The only guarantee of correctness, regardless of whether your language is strongly or weakly typed, is whether it passes all the tests that define the correctness of your program. And you have to write some of those tests yourself. These, of course, are unit tests.
This should help as a starting point in the static vs. dynamic typing discussion. Unit tests are a great invention, I suggest you have 100% CC coverage. But don’t read those comments on dynamic languages and feel safe. You need to write tests, otherwise they will not help you.
December 11, 2008
Currently the counter is at 249.000 commentes blocked by Akismet on this blog. With a rate of 500 spams/day the 250.000 mark is approaching fast. Not sure how to celebrate :-)
Update: 250.433 SPAM comments caught!
December 10, 2008
The best take-away pizza in Berlin you can get is the one at Dirty Harrys, Schivelbeinerstr (right across the street where I live). 23cm, fresh, very good taste, full of toppings, very friendly, 2 EUR.
Go there if you’re visiting Prenzlauer Berg.
Only bad thing about Dirty Harrys: Closed on Sundays :-(
December 4, 2008
I’m always on the search on good interview questions as I’m doing a lot of IT recruiting. Sometimes in interviews I talk about books the candidate has read recently, to gain some insight into his interrest and enthusiasm - Amazon looks into enthusiasm as an indicator for good candidates.
Another approach to gain some insights into candidates is to ask them about the 5 best software development books, which he considers must-read-books, and why those made it into their Top 5 list. I’ve written about books I consider good,
My personal list would be something along the lines of:
- Refactoring
- Patterns of Enterprise Application Architecture
- Clean Code and other books by Robert C. Martin
- Domain Driven Design
- All McConnel Books (Rapid development, Code Complete, Software Estimation,…)
- The Pragmatic Programmer
- Implementing Lean Software Development
- The GoF book
- The Practical Guide to Defect Prevention
(Not on the list are psycholocial books like Influence, design books like About Face, compiler or programming language books, I concentrate this post on software development books in the stricter sense.)
Getting people talking about the books they like, or the recent books they’ve read and don’t like, gets most of the candidate emotional and involved. They show enthusiasm (or not). Don’t hire those who do not read books (my opinion) or don’t show enthusiasm for topics of books (positive or negative).
Bonus Point: And most of the time I learn something about books I haven’t known yet.
Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
December 2, 2008
I have an Iphone with an edge data flat and a 300mb limited HSDPA plan. As a curious guy I want to know how much I have used of those 300mb HSDPA. Calling T-Mobile for 3 times results in three different opinions:
- Callcenter person 1: I should wait for the next month, then I will see the usage in my T-Mobile account (One month later I see nothing)
- Callcenter person 2: I can’t look online but I should call the call center to ask, they will tell me (and the employee told me my usage, 41mb of 300mb back then)
- Callcenter person 3: No one knows how much I’ve used. They can’t see it in their computer (I wonder how the second one could know) and it’s not possible for me to see my usage
Isn’t that funny? I have a limited data plan, but they can’t tell me and I can’t see my usage? They are able to monitor all my calls and monitor all my usage and tell (on demand ;-) the police, but they can’t tell me how much I’ve used? They can limit my flat rate to EDGE after 300mb, but they can’t tell me how much I’ve used already? And I can’t see?
I’ll call tomorrow for a fourth opinion ;-)
November 29, 2008
Added Xbox Live Avatar to the sidebar, Microsoft did a good job (this out of my mouth!) with the avatar generator in the new Xbox 360 console.
November 27, 2008
I wish Scala would have native support for types. Currently in Scala you need to write classOf[Person] for the Java Person.class expression.
It would be nice to have something easier than the noisy classOf e.g. when using Google Guice. Because using Guice with Scala looks ugly. I know I could do DI without Guice/Spring in Scala, but for varios reasons I don’t want to follow Jonas approach for now.
I think Groovy can just use Person for referencing types, but something like #Person would be ok too.
November 23, 2008
In January this year I’ve written about the future of functional programming in 2008, specifically about Scala and F#. Now that the end of the year nears, I’m going to look at my predictions and see how I fare.
In 2007 lots of people claimed that this year would be the year of functional programming languages. One quote I used in my post was from the website lambda the ultimate:
“My prediction is a little bit more conservative, but I predict Scala will gain momentum, and at least one high visibility project will use Scala”.
I was more than sceptical
A safe bet, really? [...] Don’t kid yourself. There will be no rise for application and especially enterprise development in functional programming.
mostly because I’ve seen the shift for languages taking a very long time. It took decades for people to move from C-style procedural code to object orientation. And though functional languages have been around forever, they haven’t started their ascend into the mainstream yet. But there was also a curious and hopeful tone in my post nevertheless:
They both are the most promising functional candidates when it gets to momentum. The transit for C# and Java developers seems to be easiest compared to other languages.
After nearly 12 months have passed, now let’s see what 2008 brought us concerning functional programming, especially Scala - as I specifically mentioned Scala in my post and because I know most about Scala from the bunch of functional languages.
A lot has happend to Scala in 2008 for sure. Even CIO.com mentions Scala in a Scripting Language comparison:
Scala is particularly attractive to Java developers.
(not sure why they call Scala a scripting language ;-)
Some real examples have shown up. Those include the real world Scala examples by Jonas Boner and Twitter. This matches with the “a high visibility project will use Scala” prediction. Some droped Scala in their development though. What hasn’t happen in 2008 is that greater numbers of developers moved from Java to Scala or bigger numbers of developers moved to Scala from other languages. As The Disco Blog writes in a comparison between Scala and Clojure:
What remains to be seen is if they can compellingly convince the Java market to learn their way of programming rather than leveraging what’s home (i.e. the Java language) for the majority of their respective target audiences.
Books
Often books are cited as one indicator for momentum in programming languages, which sometimes is problematic as I’ve written before. Scala has been quite successful 2008 with books. There are three, one released and two announced for 2009:
Growing pains - syntax debates
Guido van Rossum, the Python inventor, had some troubling words to say about Scala:
Perhaps my biggest disappointment in Scala is that they have so many rules to make it possible to write code that looks straightforward, while being anything but — these rules all seem to have innumerable exceptions, making it hard to know when writing simple code will work and when not.
Following one debate about Guidos post on the Scala debate list, there are many counter points raised. Sadly the bigger number of commentators want the language to stay the way it is. It seems only David R. MacIver wants to change the language to make it easier. I strongly agree with him and Guido that there are parts which are inconsistent, which need to be changed to get Scala into the mainstream.
What bothers me personally with Scala? It’s not that well integrated with Java as it could be. In my post on Clojure vs Scala I mentioned that already:
But the idea of Clojure - tight integration with Java through Iterable and Iterator, implementing Java interfaces, but keeping immutable structures, compared to Scala which creates it’s own incompatible versions, should prove much more successful. I like that definitely way better, Scala should adopt that approach.
And they should drop .NET support. It looks like nobody uses it and it hampers Java integration. Drop it.
But Guidos post has some hope in it too. Alex Paynes comment to Guidos post says:
I’m seeing more and more programmers getting real work with Scala, not musing about its theoretical possibilities. I find that pragmatism encouraging.
Competitors
The success of functional programming - in this case Scala - depends on competitors. How did they do in 2008?
I see two competitors to Scala. They mainly arise from the notion of Scala as a Java successor - which is the main market for Scala I think. Not much people will come from the dynamic language camp (some who might be fed up with large Rails code bases), not much from functional programming. Most are current or former Java developers.
The first competitor is Clojure. Why? It has a big momentum and a lot of buzz. Rich Hickey seems to be an approachable, knowledgable guy who can give good speeches. He does a lot of things right. But Clojure is mainly a Lisp style language. And lots of people don’t like S-Expressions because they find them unreadable in quantities. It’s also not focusing on OO style development, when most people today agree that OO is a good way to model business problems. Scala will win over Clojure I guess.
The second, and more important competitor, is Groovy. It’s been in this space for quite some time, but with the recent aquisition of G2One by SpringSource I guess it will make a big jump into the enterprise. SpringSource has a lot of good speakers at conferences who are also quite good sales people. Groovy had some problems, but mostly adapted, made it’s syntax easier, added powerful features and got faster. The Groovy vs. Scala debate might be more about dynamic vs. static typing (see last comments by Paul and James) and might be decided by the type issue.
All in all the competitors seem to have done better in 2008, with Clojure getting momentum and mentioned pratically everywhere and Groovy with the G2One takeover.
Killer applications
There is still no killer application in 2008 for Scala. Ruby took a decade to get momentum. There was some momentum when I developed in Ruby at the end of the 90s (mostly by Java people who were agile and fed up with Java), but this momentum got Ruby nowhere. Rails as a killer application for Ruby let the number of Ruby developers explode. In a way that today Rails and Ruby are synonymous, very few people use Ruby without Rails.
What could a killer application for Scala look like? A Rails clone? David Pollaks Lift didn’t make it. Perhaps it’s actors or a application server build on actors (comet friendly, scalable) is the killer application for Scala. Other ideas? Mainly the lack of such an application explains the slow growth of Scala in 2008.
Conclusion
And in the end? I’m more optimistic about functional programming than at the beginning of 2008, although the TIOBE index for 2008 doesn’t look that promising for functional languages.
Object-Oriented Languages 57.9% +1.6%
Functional Languages 2.6% +0.4%
I mostly think now OO and Functional Programming will work together in the future to write good software, and OO languages will borrow more things from functional languages. I’ll write a deeper post about how OO and Functional Programming fit together for sure.
This was a post mostly about the future and state of Scala. Wasn’t it supposed to be about functional programming? Following blogs and debates it seemed to me that other functional languages didn’t move in 2008. Erlang had some hype during the summer, which ebbed too soon. Haskell didn’t move, it’s still the promising functional language it had been for years. F# did move, but beside the promises by Microsoft I didn’t see any breaktthroughs in 2008 (perhaps I haven’t looked in the right places).
Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
Update: See the impressive comment by Don Stewart about the growth in Haskell this year. Looks like real momentum, contrary to my (obviously wrong) perception ” Haskell didn’t move, it’s still the promising functional language it had been for years.”
Update 2: Good points made in comments: IDE support got much better 2008 in Eclipse, Netbeans, Intellij. Bad points: High profile googlers seem not to like Scala.
November 20, 2008
Looked at the current November 2008 TIOBE programming language index, found via Cedrics Twitter. Java still on top, very slow slide, Ruby down by 2 places, no longer under the Top 10, C++, C# and especially Python up, PHP still 5th, Erlang at 31st, Scala at 43rd ;-) F# not listed in Top 100.
Other interesting tidbits:
“The object-oriented paradigm is at an all time high with 57.9%. The popularity of dynamically typed languages seems to be stabilizing.”
Object-Oriented Languages 57.9% +1.6%
Functional Languages 2.6% +0.4%
Statically Typed Languages 60.0% +1.2%
Dynamically Typed Languages 40.0% -1.2%
(after some big increases for dynamically typed languages since 2002)
November 19, 2008
Why do management consultants get so much money? Why do managers hire consultants? From my experience both as someone who did hire consultants and someone who was hired as a consultant, there are (beside lots of other reasons) three major reasons for hiring consultants. You hire consultants because
- you need people for a job (fast or temporary) but can’t hire them yourself (body leasing)
- you need special expertise (e.g. m&a) which you don’t have
- you outsource decision making and being responsible
The first and second are obvious, but the third one is the most interesting one I think and a major reason for the amount of money in the consulting business.
When your’re a manager, you have mostly two jobs: make decisions and take responsibility. Often you also have a budget. The best you can do now, is hire a consultant with your budget to make the decisions for you and also take the corresponding responsibility. What’s left for you to do? Nothing. Mission accomplished.
Say you’re an IT manager and want to buy a new CRM. You could either look into it, delegate due diligence and make a decision. After the CRM software fails you need to take the responsibility (if you can’t deflect it) and get fired.
Or you could take your budget, hire a consultant who decides for you what system to buy (or what product to build or what market to enter or which competitor to buy, it doesn’t stop with IT decisions). Then you tell everyone “Accenture told me to buy XYZ”. If the software fails, tell everyone “Bain told me so and they have the brightest people. How could I know better?”. This even works when you’re 15 years in the ABC business and the consultant is someone fresh from an ivy league school with no experience. Astonishing.
It also explains why the top consultancies hire the brightest people. Not because they need bright people for their projects. Most consultancies just resell their knowledge again and again, no bright people needed. But
- they have the money to hire the best
- their clients can fall back to the line “McKinsey has the best people. If they didn’t know XZY wasn’t right, noone could know!”
So this is a very profitable and symbiotic relationship between managers and consultants, which explains why manager outsource their core duties.
Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
November 17, 2008
I was reading the Feynman report about the Shuttle disaster: “Appendix F - Personal observations on the reliability of the Shuttle” and I was freaked out by the similarities of military engine development and bottom-up, test driven development. There is a small passage in the report about how military engines are built:
The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), and tests are begun in experimental rigs to determine those. With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood. There is a very good chance that the modifications to the engine to get around the final difficulties are not very hard to make, for most of the serious problems have already been discovered and dealt with in the earlier, less expensive, stages of the process.
This sounds a lot like Unit Testing to me. Writing small parts of an application, testing the part, then integrating it. And even if this is not TDD (not possible with hardware?), then it sound similar, contrary to writing all code first and writing the tests last.
Compare this approach with the way NASA desigened the Shuttle Main Engine:
The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes. For example, cracks have been found in the turbine blades of the high pressure oxygen turbopump. Are they caused by flaws in the material, the effect of the oxygen atmosphere on the properties of the material, the thermal stresses of startup or shutdown, the vibration and stresses of steady running, or mainly at some resonance at certain speeds, etc.? How long can we run from crack initiation to crack failure, and how does this depend on power level? Using the completed engine as a test bed to resolve such questions is extremely expensive. One does not wish to lose an entire engine in order to find out where and how failure occurs. Yet, an accurate knowledge of this information is essential to acquire a confidence in the engine reliability in use. Without detailed understanding, confidence can not be attained.
A further disadvantage of the top-down method is that, if an understanding of a fault is obtained, a simple fix, such as a new shape for the turbine housing, may be impossible to implement without a redesign of the entire engine.”
This sounds a lot like traditional, up front software development. With the same problems. When errors occure, “are they caused by flaws in the material [...]“ or where do they come from? It’s hard to decide which component is the root cause of an error in a complex system. Astonishingly Feynman sees another corresponding disadvantage with top-down versus bottom-up. Problems that arise may be too big to fix in a conventional way, the engine architecture needs to be redesigned. This happens with software too. If you do too much up front architecture, you may end with an architecture which doesn’t fit your problems (usually this means a long and difficult rewrite - something you should only do as a last resort). Going bottom up, best with Test Driven Development (TDD), you can’t end with a wrong architecture (with merciless small refactorings and path adjustments on the way of course). And usually you’re flexible enough with an architecture which was driven by unit testing to react to all changes on your way (scalability, performance etc.)
The engine development success and the shuttle problems compared show convincingly how developing in small steps with components and merciless testing results in easy to debug components with a low error rate. You should test more.
Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled).
November 13, 2008
I’m playing with a new blog layout. Much simpler than the last, more whitespace. With an urgently needed upgrade of my Wordpress version and some new features like Twitter integration. I’m not yet satisfied with the results, the balance doesn’t look right yet. But overall it’s the right direction, especially with more vertical space for text.
November 12, 2008
You can now follow me on Twitter, at last :-)
http://twitter.com/codemonkeyism
November 10, 2008
My hoster needed a second downtime, to remove the old harddisk (160gb), not sure why he needs that and why it couldn’t stay in the server. Sorry again. And there will be a 3rd downtime, because my hoster found a RAID controller in my server which shouldn’t be there. And he wants to remove the controller and get me a 3rd downtime. How unprofessional.
Update: The support was very supportive, the issues are resolved and no 3rd downtime needed.
Some of the ego or third person shooters I’ve played more or less recently (2 years?) and how I liked them, the best one first. If you’re only interested in programming, stop reading.
- Half Life 2 + Episode 1 + Episode 2
Best shooter (ever?): Very good story, nice graphics, atmospheric (landscape), memorable scenes (Nova Prospekt, sea side road)
- Bioshock
Creepy, very good/dense atmosphere, good story, nice graphics, didn’t like most of the powers, end boss wasn’t that good, didn’t fit the story I think
- Resident Evil 4
Shocker, very good game, sometimes very creepy, lots of enemies, replay value because of different level design with different difficulty
- Dead Space
Very good graphics, Zero-G and vacuum are stunning, sometimes - too seldom - creepy, I was often reminded of RE4, for example the scene where you have to protect Nicole (and some other scenes). The other game that comes to mind when playing Dead Space is System Shock (one of the best) - for example the elevator scenes, hydroponic and general feel
- Metroid Prime 3
Good atmosphere, innovative, I like the Metroid Prime style. Not a shooter, more a 3d action adventure like the old Metroid Primes on the NES/SNES
- Portal
Short but innovative and good story - a shooter?
- Halo3
Very good story, very film-like, especially the end, I would liked to have more “Ring scenes”
- Call of Duty 3
Good action, some very good scenes (battle on the last hill) - too few though
- Far Cry
Nice trees, nice plants, large landscape, didn’t like the story very much, the end game was getting worse
I would buy and play all of them again, except perhaps CoD 3 and Far Cry. Probably I’ve forgotten some I’ve played, but then they couldn’t have been that good, could they? And yes, sometimes I play too much (ask my girlfriend ;-) - not that often and not for very long, ego shooters are way too short :-)
Update: Some don’t like Dead Space: “Oh dear Science. It’s so derivative. It’s sooo been done before, that it’s really kind of embarrasing to sit through the story as it unfolds exactly as you’d expect.”
I didn’t expect this to happen. I thought they would more reference half life and the military would come in and shoot everyone. I was suprised ! Other than that, yes it’s predictible. But a nice game.
November 9, 2008
Sorry for the downtime, the hardware upgrade and Debian to Ubuntu migration didn’t work as expected due to mistakes by my hoster. Thanks for coming back.
November 4, 2008
I currently think about the question: “Is Java dead?” with some introspection into what dead means, what Java means, jobs, market and everything else. Playing with Google trends and Indeed, a fun comparison:
Inspired by Obie.
Another one I found interesting (Ruby growing in sync with Rails):
If you feel inclined to comment on the information content of Google trends or relative Indeed comparisons, don’t. There has been enough discussion already and the grain of salt everyone takes is big enough. Thanks.
Currently attending the Java/Enterprise/Agile/Osgi/SOA W-Jax 2008 conference in Munich. Really nice up to now.
October 31, 2008
Good news:
“Google Guice Plugin 1.0 M1. Supports discovering new Google Guice (implicit) components, adding/removing implicit setter and field dependencies and reconfiguring @Singleton’s.”
October 27, 2008
Sorry for the inconvenience, got slashdotted by reddit. Never thought so many were
interested. And no, scaling was not one of the reasons the startup failed ;-) No ssh from my work so it took some time to fix it. Thanks for coming (back)
During the dot com boom I founded a software startup with some friends - with me as the CTO. We developed a software for knowledge management. It was a combination of blogs, wikis, a document management system, link managment, skill managment and more. We started in 1999 which was quite early for wikis and blogs (Moveable Type was announced 2001). The link management system was essentialy the same as Delicious later. Beside all those new ideas (for 1999 at least) there were three great features:
- Everything could be tagged. Skills, people, links, documents, blog posts, wikis, something which is today called folksonomies. Tags could refer to other tags to form onthologies. Tags could link to other documents, blog posts, persons.
- Everything could be rated from 1 to 5
- We had a clever fuzzy search based on tags and ratings. Searching for “people with oracle knowledge” would also reveal experts for SQL Server - for example to stuff your project if an Oracle guru wasn’t available
We’ve got quite some money as a seed investment from a VC and were quite happy and successfully developing our application. We did show it to many users and received very favorable feedback from big companies. Why did the startup fail and I’m no millionaire? There are a myriad of reasons, but as I wrote in “Rules for a successful business”, the rules for a sucessful business are easy:
- The customer is the most important thing in your business
- The best business plan is to sell people the things they want
- Your business is successful if your earnings are higher than your spendings
So the most important thing is to sell - a fact lots of startups forget. And we did too. After much thought it comes down to these six reasons why we failed (beside the obvious one that the VC market imploded when we needed money and noone was able to get any funding):
- We didn’t sell anything
- We didn’t sell anything
- We didn’t sell anything
- The market window was not yet open
- We focused too much on technology
- We had the wrong business model
In more detail:
We didn’t sell anything, Part 1
We didn’t sell anything because we didn’t have a product to sell. As good engineers we wanted to wait until the product is finished and then start selling. Midway we started selling nevertheless with a nearly finished 1.0. This led to too much focus on development and not enough on sales. Without a finished product we thought we couldn’t go to customers and try to sell it. We’ve slowly learned two things:
- You don’t need a product to start selling if it’s software. The first sales meetings with managment were perfectly possible with screenshots, mockups and slides. As the topic was new to our customers, we first needed to convince them on the concepts (wikis, blogs, tagging) and that could be done without a finished product.
- Start selling before you found the company. Start selling now! You do not need to have a company to sell new ideas to customers. Start selling now! When people really want to buy your product, start the company.
We didn’t sell anything, Part 2
We didn’t sell anything because we had no sales person. Bummer. Of course we were looking for one and the business plan said: High priority is finding a sales person for the founding team. This took time and resources and we didn’t have that. If you want to sell something, get a sales founder or hire someone from the start.
We didn’t sell anything, Part 3
We didn’t sell something because customers wouldn’t buy. The product was great, the customers favorable, but they took too long to decide. We wanted to sell a knowledge managment tool bottom up to project managers and through them to companies. But everytime a superior heard of knowledge managment he decided it should be on his agenda. So the topic of knowledge managment moved up the chain of command and we had no real decision maker. We talked to irrelevant people (because the topic became strategic fast for our customers) and lost lots of time. Ask people if they are allowed to buy your product. Get to the one who says “Yes” fast. We had several big companies in our sales queue and I’m sure they would have bought in the end, but as a startup we couldn’t wait. SAP for example compared to us could have waited and sold the product after 12 months. Selling enterprise software takes a lot of time.
The market window was not yet open
The market window was not yet open. Noone heard of blogs, wikis and tagging. We had to educate our customers on the benefits of wikis (Everyone can edit! Everyone! How dare they!) and blogs (Everyone can have an opinion and write about it! Everyone!) and tagging (They can build ontologies! We need a comittee to define an ontology for everyone! Otherwise chaos will eat us!) Several years later it would have been much easier to sell a blog, wiki and tagging plattform.
We focused too much on technology
All the founders were interested in technology. We’ve worked with EJBs (not mature back then), we made everything spit out XML and rendered that to HTML with XSLT (not fast enough), wrote our own OR-Mapper - what a stupid idea (Hibernate not available), tried CSS driven websites (not enough knowledge available back then). This lead to rewrites and took lots of our time. Discussions about technology - we should have talked about customers - took time too and led to frustration.
We had the wrong business model
Plain and simple: we had the wrong business model. Selling software can eventually reap lots of money, but it takes time. We had upfront costs, making sales deals took a lot of time and we burned money without income.
The better model would have been: Do consulting on knowledge management and start with an open source product.
We did consulting to companies on how to do knowledge managment, use wikis etc. But we didn’t take any money for it, because it was part of our sales process. Focusing on cosulting and billing people would have created a steady income.
I did get into open source later with SnipSnap. SnipSnap took (a small part of) the ideas from the startup (wiki and blog) and was relased as an open source tool. Lots of people downloaded the software and installed it on their desktops. We really made installing SnipSnap easy, so it spread fast. I’ve talked to a boss of a very big software and consulting shop and he told me, wikis would never work for them: too chaotic and not structured enough. Well - in fact I knew that there were several SnipSnap installations in his company :-) As others are practicing now we could have gotten our foot in the door with an open source project, then sell support and enterprise features on top. Companies later paid us money to put features into SnipSnap, make it scale better and for other enterprise thingies. But in 1999 we didn’t know as much about software business models as we know now.
What can you learn from my mistakes? Not sure, but start selling. I’ve learned a lot though about software managment, products, business models, money and being a CTO.
Thanks for listening.
