Google Chrome OS – what’s the big deal? July 9, 2009
Posted by Wille in Emerging Trends, Entrepreneurship.add a comment
Google have announced their plans for an Google Chrome OS for netbooks and laptops, based on Linux.
Business- and tech media are falling overthemselves fawning over this new OS that no-one has even seen yet.
Apparently the OS will be primarily running a web browser. That’s it.
Fawning over Google Chrome OS – isn’t that just a little bit like it would have been to get your panties in a twist about the announcement of a terminal only OS in 1995? More or less a non-event.
I realize that Google are shooting for the Netbook space, and yes, that to a large extent the browser and browser based applications are now more important than native desktop applications. But really, is a severely limited OS anything to get all excited about?
The iPhone did not become a hit because it was more limited than existing smartphones, on the contrary, it was even more sophisticated than existing smartphones, but was so with the simplest, most user friendly interface ever deviced for the form factor that it was released in. There is clear value in simplicity and limitations from a usability perspective, but simplicity in usability is not the same thing as being severely limited technically.
Furthermore, Google creating a browser centric OS proves my previous point of Google thinking too much inside the box, the box being the browser.
Personally I believe a large part of the next wave of innovation on the web will be in the form of rich desktop applications that synchronized and pull the bulk of their data from the web, but process and present it primarily on your local device. This is already happening, just look at Spotify, TweetDeck, JungleDisk, Skype and any old Instant Messenging client.
Thinking of the web and internet as HTML and JavaScript only severely limits the possibilities and avenues of innovation.
It is starting to look like this might be Googles future achilles heel.
Risk management or ass-cover management? July 8, 2009
Posted by Wille in Corporate Stupidity, Management, Software Development.1 comment so far
Have you ever come across an organization that wants to be “standards compliant” at any cost? Prefers using a large vendors inferior software over better open source software? Wants grand buzzword compliant architectures over simple software that works?
Large organizations tend to have a culture whereby people’s concept of “risk management” is not managing real risks, but rather second-guessing where future blame might be assigned.
Risk management in many organization should not really be called risk management, because no such thing actually occurs, it should be called “ass-cover management”.
It should be called ass-cover management because it is exactly what it is – actual success or failure doesn’t really matter that much, the main thing for employees in these organizations is to be in the clear once the inevitable process of blame assignment commences.
When the blame-storming starts, you don’t want to be the guy that signed off on a “non-standards compliant” solution, because as we all now, using “standards” ensures 100% likelihood of success all the time (or NOT). You need to be able to blame the vendor, who obviously wasn’t standards compliant enough, or the consultants who weren’t up to CMMI level 873 as they claimed during the lengthy procurement process.
It’s easy to blame project management in these situations, but often they are driven by fear – they cover their asses for a reason, as psychology dictates, the environment conditions the behaviour of people in it.
It takes a lot of backbone for someone to stand-up alone and call “Bullshit!” on this sort of organizational behaviour. But I don’t think there is any other way around it – people need to at least be eased into the understanding that their behaviour is counterproductive, that they are in effect not managing risk at all, they are only managing future blame.
Perhaps the most damaging aspect of ass-cover management is that it presupposes failure: if you are already managing the blame for future failure rather than real risks, you have already accepted failure as an outcome and likely doomed your project to that very result.
Having a higher success rate for projects might actually be as easy as realistically trying to achieve success, rather than being driven by an irrational fear of failure that becomes inevitable the minute you submit to it.
The question is, is your project doing risk management or ass-cover management?
“Enterprise security and reliability” – what does it actually mean? Really? July 7, 2009
Posted by Wille in Corporate Stupidity, Emerging Trends, Software Development, Technology.add a comment
Sekhar posted an interesting comment on my previous post about the emerging service infrastructure in the cloud:
The mash-up/pipes approach you’re talking about I guess works for general apps in web/extranet setups, but for corporate intranets where workflows must be secure/reliable and support transactional semantics, a tightly controlled setup would work better.
Sekhars comment highlighted something interesting in my mind – to play a bit of devils advocate on purpose: do they really need the secure/reliable infrastructure? Secondly, are they really secure and reliable inside the corporate firewalls? Thirdly and most importantly: is it ACTUAL security and reliability, or just perceived security and reliability that large corporations strive for?
Most enterprises tend to worry about security and reliability in much the same way a drunk worries about keeping his belt tight all the while his balls are hanging out through the zipper – they are anal about all the little things, while letting the obvious, gaping holes slide. Where budgets are big, common sense is often short in supply.
How many have come across the enterprise where anal rules about security focus on all the wrong things, while completely forgetting about the blindingly obvious? I remember one place where camera phones where banned because of the perceived risk of industrial espionage. Nobody seemed to have thought about the fact that anyone could just e-mail any old file as an attachment to the outside world without anyone being the wiser.
Further, how many people have had their e-mail inboxes barraged by announcements about this or the other corporate IT service being down either for maintenance, or just due to a system crash? Who do you really trust for uptime, Google and Amazon, or your trusty old corporate IT-services who sometimes seem more interested in donuts than keeping your essential servers alive?
Talk about “security” and “reliability” in an enterprise context often presupposes that services are somehow magically more secure and reliable because they exist behind a porous corporate firewall. Questions about ACTUAL reliability, guaranteed uptime and security against hackers are rarely if ever asked, it is mostly about perception and buzzwordiness and less about the actual reality.
If we are to have a serious discussion about security and reliability and all those other important sounding things, we should dispense of the buzzwords and notion of the super-magical corporate firewall, and get down to what security and reliability ACTUALLY mean and how they can be met. All to often we just throw around important sounding words without stopping to think what they actually mean.
Scala – is the buzz getting close to critical mass? July 6, 2009
Posted by Wille in Scala, Software Development.add a comment
It seems the Scala buzz is building. James Gosling, the father of Java himself has given a ringing endorsement of Scala, as has the primary driving force behind JRuby.
Today, James Strachan, the creator of Groovy has joined the chorus, saying he prefers Scala to Java, and that had he known about Scala in 2003, he might not even have created Groovy!
Each on their own could have been dismissed, but put together it is starting to show a clear consensus from some very influential voices of what I have already expressed is likely: Scala is the heir apparent to Java.
But assuming Scala is becoming “mainstream”, how long will it be before we see widespread corporate adoption?
I wouldn’t get too excited just yet, Scala WILL probably overtake Java at some point, but it might take a while. Companies have large investments in their Java codebases and more importantly Java skills, interoperability with Java will help, but it won’t happen overnight.
We might be in for a long, hard slog before Scala actually overtakes Java as the language of choice in the corporate world. Most likely the change will be driven by the open source movement and smaller, entrepreneurial companies that have less sunk cost in the Java world and more openness to trying new things.
On a personal note, I said a few months ago I would give Scala a rest, with a view to revisiting it soon. Soon might have been sooner than I thought: my brief fling with Scala exposed me to a lot of annoyances with Java I had never paid attention to before – verbosity, idiosyncratic syntax etc etc. It is quite likely I will start using Scala again this summer, at least around the edges of some of the smaller things I am working on so as to optimize the learning curve/productivity trade-off.
Battlestar Galactica – an epic masterpiece July 3, 2009
Posted by Wille in Books & Culture.1 comment so far
I recently bought all seasons of the 2004 re-imagining of Battlestar Galactica, and I have not regretted it one bit. It is an epic masterpiece, and probably both the best TV- AND movie experience I have ever had. It is literally like watching a 50 hour movie, rather than a 75 episode TV series – the quality is great throughout, there are no “no progress”-episodes, no dragging out things because the network didn’t know for how long they wanted the show to run – it is constant progress towards the last episode.
Battlestar Galactica circles around the survivors of the human race in a distant part of the galaxy following the nuclear holocaust of their 12 home planets, “The Twelve Colonies”. Hunted through the galaxy by the Cylons, a cybernetic race once created by mankind and responsible for the holocaust, hell-bent on the extinction of mankind, the humans fight for their survival while they search for a new home and a mythical lost planet called “Earth”.
The show is a Science Fiction show, but above all it is a character and story driven show that deals with religion, philosophy and existentialism – what does it mean to be human, what is a human? Can you find redemption for your sins, however bad? Are there higher forces at work? The themes touched upon are large, and left largely to the viewer to make their own judgement – characters are not inherently good and evil, just flawed. Some people you sympathize with initially you will loose sympathy for, and vice versa.
The fact that the humans believe in a polytheistic religion with many Gods, while the Cylons are fundamentalist monotheists that believe in “One True God”, also opens up for a number of themes around religion, which is central throughout the series, in particular towards the last three seasons.
Throughout the show, there are many themes that run parallell to modern human history in general, and post 9/11 history in particular, however the show takes great care in not pre-judging the moral issues, rather it skillfully holds up a mirror to society and lets us reflect on the questions ourselves.
For me, Battlestar Galactica is probably THE defining TV- and movie experience of my life, it is nothing short of a 50 hour masterpiece and showcase for great acting and masterful writing. I was filled with a certain sadness yesterday as I watched the final three episodes of the show, but at the same time happy with how all the loose ends got tied together.
If you have never seen Galactica, or not seen it in it’s entirety, I strongly recommend it. The first few episodes can be a bit heavy, but once you are into it, you will be itching to see the next episode, and the next, and the next..
The future is “Service Oriented” (just not the way Enterprise Architects imagined) July 2, 2009
Posted by Wille in Emerging Trends, Entrepreneurship, Management, Software Development.5 comments
SOA, ESB’s, SOAP and a plethora of other alphabet-soups colluding to increase, not decrease complexity have plagued enterprises and enterprise software for years. Enterprise software vendors, consultancies, and “analysts” such as Forrester, Gartner et al have been at the center of this movement, eagerly cheered on by Enterprise Architects whose careers depend on creating complexity they then get paid top dollar for to manage.
Calling SOA in its enterprise incarnation a spectacular failure would be the understatement of the decade. SOA efforts in most enterprises have not lead to cost savings, they have led to bewildering complexity and massive sunk costs. Complexity disguised as “consolidation”, “standards compliance” or “re-use” can simply never succeed.
The irony of this whole affair is that the promise of “SOA” already had been delivered in other areas – it’s called the Unix-approach, small and simple applications that only do one thing, but do it well, that can be piped together into a bigger whole.
What worked for the Unix-approach was that it was not top-down based as most modern SOA efforts, instead it was a bottom-up approach: little utilities where built to scratch a particular itch. Eventually it emerged that these little itch-scratchers could be combined to scratch even bigger itches, but this was not by design, it was by virtue of being small, specialized and good at one thing only.
This specialization is emerging once again outside of the Unix OS, in what is buzzwordily referred to as “The Cloud”: Google Apps can be used for e-mail and personal productivity, Twitter for messaging, RSS for information distribution/dissemination, Google Maps for location aware services and context, Amazon Web Services for computing and storage.
Small pieces, loosely joined. What they all have in common is that they did not emerge out of some grand, top-down scheme, but as individual services designed to do one thing only, but do that one thing well.
By “accident”, it just so happens to emerge that these services created by disparate organizations for disparate reasons actually provide the infrastructure for most of the computing and communication needs that exist in organizations large and small. Integrate them and you have something very powerful, based on Service Orientation if you will, build more small features and services on top of them, and you can potentially unleash yet another wave of innovation and improvement.
The future is Service Oriented, just not in the leviathan top-down way that Enterprise Architects around the world imagined – the Service Orientation is open, and it emerges from the bottom-up, almost by accident as a multitude of people and organizations scratch their own itches, then find ways of combining their own services with those of others again and again in new ways and permutations.
Why Agile works: it mimics a market economy July 1, 2009
Posted by Wille in Agile, Investing & Economics, Management.2 comments
In these challenging economic times, praising the virtues of the market economy is not exactly in fashion, and for good reason: the “efficient markets”-hypothesis has been blown out of the water spectacularly.
But even with all it’s failings and inefficiencies, the market economy is the greatest creator of wealth for all of mankind throughout history: feudalism failed because it was hereditary and not meritocratic, socialism failed because of it’s inefficient command-and-control nature that ignores feedback. Markets are fallible and flawed, but given all available systems of economic organization, it is still the best we have – the price mechanism is the best feedback mechanism ever to exist.
Similar things can be said about Agile software projects. They are by no means assured success, nor are they ever perfect in execution or outcomes.
But I would argue that when Agile works, it is not because of individual practices, but because as a whole it mimics a market economy with a high level of accuracy:
- Short iterations, fast customer feedback mimic the markets pricing mechanisms: either customers like what has been built, or they don’t, just as in a market customers will either buy your product at a given price point, or not.
- Self-organizing teams mimic the autonomous actors in a marketplace: teams self-organizing means people will naturally supply their “services” in a team where they are needed, they find a “market” for their skills within the team, rather than being told by a “socialist” central planning committee what to do (even if it wastes their efforts).
- YAGNI/simplicity means you do not add in features unless they are “saleable” immediately: doing the simplest thing possible that works means you only do what there is demand for, and what there is the most demand for at any given time. Your “supply” responds to what there is the highest demand for, nothing else.
Short iterations, fast feedback, self-organizing teams and a YAGNI-approach to features are all intrinsically market-based principles, Agile works (most of the time) due to the same reasons that markets work (most of the time).
If you have experienced failure in supposedly Agile projects, ask yourself: was the team REALLY self-organizing? Did management really trust the team to work it out for themselves?
Did you REALLY do frequent releases, getting early and frequent customer feedback?
I would argue that for an Agile project to be successful, following market-based principles is far more important than any individual practice. Agile, just like a market is not infallible, it is still subject to the whims, skill and intelligence of its actors, but all things being equal, market principles trump old school socialist command-and-control hierarchical management of resources any day, be they financial or human skills.
How to NOT get me to buy your software June 29, 2009
Posted by Wille in Entrepreneurship.1 comment so far
I have been evaluating IntelliJ IDEA for the past couple of weeks, and it is a great piece of software, if somewhat pricey and a few rough edges (code formatting and lack of complete round-trip compilation being two of them).
I considered buying a license, but noticed that they only allow upgrades for bug fix and minor number releases on a license. A major number release requires buying a license upgrade. I e-mailed JetBrains sales to verify this so I was not missing anything, and sure enough, my analysis was correct. With their planned release of IntelliJ 9 in Q4, this means I would require an initial outlay of £180 for the version 8 license, and a further outlay of £100 to keep up to date in the next 4-5 months with the upcoming version 9.
This is a schoolbook case of how NOT to get me to buy their product. I have no interest in paying twice for the same thing in less than six months just to keep up with versions, especially when the one-time price alone is steep enough. I’ll stick to NetBeans, thank you very much.
This might seem like I’m singling out JetBrains for criticism, and I have to re-iterate, I love their products, just not enough to pay for it twice in a year to keep up.
Anyone who works in software development will know one thing: version numbers, especially major version numbers are completely arbitrary and rarely reflect much else than deadlines and/or requirements from the marketing department. Selling licenses based on major version numbers, especially in a business where they come frequently is braindead.
In this case, I would have paid the £180 license cost in a heartbeat if I knew I had free upgrades for say 12 months from the date of purchase. I’m not paying £180 if my upgrades are going to be subject to the whims of a marketing department, especially in a global recession.
If you are selling licensed, installable software, the way to get my business is to guarantee me an upgrade path for a given amount of time. If I have to pay for upgrades, especially when a new version is on the horizon, it only means that I’ll hold off on my purchase in the best case (which means you won’t get my money for a while yet), worst and most likely case is that I won’t buy at all.
Users these days are too smart to fall for the version number game, so if you want their business, give them a clear upgrade path.
Agile, Schmagile – is it project size, not methodology that is the bane of projects? June 25, 2009
Posted by Wille in Agile, Management, Software Development.1 comment so far
I firmly believe that Agile practices, both in project management and software development are the best way to go for software projects.
However, in the debate about project methodologies, one thing often goes amiss: project size.
I would be very interested in seeing some firm numbers on project success rates on large vs. small projects for both Agile and “traditional” projects. My gut tells me that size has a lot more to do with project success or failure than any methodologies applied to a project.
As a rule of thumb, most projects I have been on in my career have followed a simple path: projects of limited scope with up to about 7 people have generally been successful with few major problems or setbacks. Projects with more than 15 people have generally been failures on some level and marred with trouble – either “just” delays and budget overruns, or outright failures.
This leads me to the simple conclusion that the best way to succeed with a £20 million project is to not have one, but instead have lots of small £200000 projects that work in isolation.
A smaller number of people, stakeholders, smaller scope and shorter timeline will all go a long way towards lowering complexity, coordination overheads and increasing accountability.
On any project, my order priorities would be (better) people, (smaller) scope, (good) methodology/practices. No amount of good process can do much about bewildering complexity and leviathan-like scope.
Scratching your own itch June 24, 2009
Posted by Wille in Entrepreneurship.1 comment so far
Some would probably look at my entrepreneurial exploits and come to the conclusion that I seem to be more prolific in building things than I am successful in selling them. Both I and my bank account would be inclined to agree.
However I do not perceive it as failure for a number of reasons: first of all, I learn something from every attempt, for each attempt I get closer to learning a formula that will give me the success I eventually want. And let’s face it: I don’t really risk getting wiped out from my attempts, they are low risk, low cost, hardware and bandwidth are extremely cheap these days, break even on running costs are just a few customers away. My only real investment tends to be a few hundred pounds and the time-value of my own time.
Secondly and more importantly, I tend not to build stuff for “others”, I scratch my own itches, I am always my first user myself, I build things I want to use myself, or at least things I think I want to use. I build things I want to use because I see other alternatives either being absent, lacking or questionable.
As long as you scratch your own itches, chances are there will be others with the exact same itch. And if there aren’t, at least you will have scratched your own.
