The future of Java
Last week (11 mars 2010), I gave an evening seminar for consultant company in central Stockholm, regarding the future of Java, in the aftermath of Oracle’s acquistion of SUN. I gave my view points on the evolution of the platform and the language. My primary point was the bright future of Groovy, as the leading JVM language. Sort of, similar to how C++ replaced C, back in the beginning of the 90s.
Here are my presentation slides.
Cloud Computing and Security
Last week (Mars 11, 2010), I gave a seminar (in Swedish) regarding cloud computing in general and the security aspects in particular, for HAS 4.0. HAS is an annual course in security with a very broad perspective, organized by Logica and Cornerstone.
Here are my slides from my two hour presentation.
Cloud Computing and Testing
Yesterday evening I gave a seminar about Cloud Computing with the bias towards testing. I have uploaded my slides to SlideShare (see below).
We got some snow
There has been some amount of snow this winter, here in Sweden. Well, we usually do have snow during the winter, but this amount is plain ridiculous. Who was that guy talking about global warming, was it Al Gone or Al Wrong?
Cloud Computing seminar at easyFairs IT-Show
Today, I gave a seminar (in Swedish) about what is Cloud Computing and how to use it. Here are my slides from the presentation.
Droid@Screen
I have recently start to learn programming Android. It’s Java, but the environment is very, very different from ordinary server and/or desktop Java programming. Mostly because the device is limited in all sorts of resources. Therefore, the API puts some burden on the lone hacker.
Anyway, I needed a simple tool to project the screen of my HTC Hero device on my PC, for showing it to an audience. I found one such application, but wasn’t really satisfied with its functionality and because I didn’t want to step on someones toes by messing around and changing way to much of the code I went for my own solution. My primary objective was to ensure it was operational before next Sunday, when I will need it.
Here is how it looks like
It is a simple Java Swing application, delivered as an all-inclusive executable JAR file. Therefore, one can launch it simply by double-clicking on the JAR file, or run the following command
java -jar droidAtScreen-0.3.jar
The Droid@Screen JAR file can be found here (pls understand it is alpha software)
Source Code
The source code is open source and I have put all of it to my git repo at Codaset.
The project is built using Maven. Before you can compile, you need to install two Android JAR files to your Maven repo. It is the android.jar and the ddmlib.jar files. Use the mvn install-file command. The easiest to get the mvn syntax right is to try compile it and wait for Maven to point out how to run the install-file command.
Screen-Shots
Here are some more screen-shots.
Landscape mode
Scaled image
Multiple windows
Save screenshots
Setting the path to the ADB executable
The application relies upon the Android Debug Bridge (ADB) application, which will be started unless it’s already running. So the very first thing Droid@Screen does is to prompt for that path.
—-
Back again
I have been, sort of, away from this blog for a while. Primarily this comes from me being occupied with lots of other stuff. The past couple of months I have been busy with teaching/training most of the time.
I have given several courses over a broad spectrum. It has been in
- Erlang programming
- Threads-programming in C++
- Java fundamentals
- Java advanced
- Cloud Computing
Over Christmas/NewYear I started to learn Android programming, which is really fun.
Posting from my Android phone
Just checking how easy it is to write a blog post using my HTC Hero Android phone with wpToGo. Although the typing on the soft keyboard is a pain.
Trends in Application Development
Last Wednesday I gave an internal seminar for a well-known and large Swedish company. The topic was on software development and I had decided to talk about my reflections/observation of software project failures.
The major theme of the speech was the paradox of at one hand we have seen a tremendous improvements of languages, tools and methodologies over the last quarter of a century , but on the other hand we haven’t seen the proportional improvement in application quality and development velocity.
Over the years I have been working in both small organizations and large organizations. Based on my own experience and observations it seems to me that the likelihood of project failure is direct proportional to the size of the organization. One explanation is, of course, that I have been particular unlucky in chosing the right kind of organization. However, my observations tend to be on par with what other old veterans admit over a beer or a cup of coffe.
The first half of the seminar describes briefly some the advances in languages, tools and methodology. That means, the affecting forces of improved software quality and development velocity. The rest of the seminar tries to analyze why, despite of the just mentioned improvements, projects still fail.
One source is the ongoing transformation of the consultancy market. The whole software industri is affected by this transition, even if a single company do not engage consultants. This transition, in turn, is a respons to the ongoing organizational optimizations large corporations exercises in order to achieve lean-and-mean cash flow.
A single consultant is a revenue unit and we can formulate its revenue as product of its utlization and the max revenue.
revenue-of-a-single-consultant
The utilization is a number in [0, 1] and captures in average the net time a consultant produces income. An emperical observation of the utilization (my), is that it is an approximate constant.
emperical-observation-1
Two other emperical observations state that the time and team size, is direct proportional to the likelihood that the hourly rate is the same as the market average.
emperical-observation-2
emperical-observation-3
This leads to we can re-formulate the consultancy equation to be a product of the utilization, the market average and the competence coefficient (kappa).
revenue-of-a-single-consultant-refined
Using this, we can formulate the revenue equation for the whole team as a product of the team size, market average, utilization and the team (average) competence.
the-consultancy-equation
Based on the consultancy equation, we can then formulate the obvious economic in-equality as the salary plus the cost contribution must be less than the team revenue. This revenue, in turn, is a linear function of the team competence.
the-law-of-gravity-for-consultancy-life
I refer to this equation as the Law of Gravity for the Consultancy Life. That means, in a short time frame it is impossible to adapt to changes in market fluctuations, as we have seen during the last year.
The consultancy buyers tend to devaluate, or ignore, the competence coefficient (kappa) and the seller naturally tend to overstate it.
competence-factor
The involved players perform different compensational strategies to lower the cost and circumvent the consultancy equation. The buyers goes elsewhere, using off-shoring to take advantage of lower salaries. The sellers, employ rookies to take advantage of of low salaries (called junior-shoring). An finally, the consultants themself in order to maintain competence-based salary improvement, has two options to choose between; job-hopping or career change.
compensational-strategies
Over time, this transforms the whole consultancy market. Let’s look at the food chain of the consultancy market.
the-food-chain-of-the-consultancy-market
At the top we have the traditional consultancy company that deliver a defined result (solution) for a defined amount of money. The trick in pricing, is of course to add some margin to account for unknowns. Based on this margin, the hourly rate might seem too high for many buyers. The hourly rate is a very concrete factor, but delivered quality on the other hand a very fluffy factor. The former is imminent before the project start, but the latter is only possible to measure towards the end of the project. Therefore, buyers tend to ignore the latter and goes for companies that offer lower hourly rates.
At the bottom of the food chain, we have the new kind of consultancy brokerage firms, that can offer low hourly rates because they have zero overhead costs for non-enganged personell (people on the bench).
Squeezed in between we have the former solutions delivering companies, that nowadays tries to survive with pure staffing business. However, in the long haul they cannot compete with pure brokerage companies.
The trend in the industry is clearly towards lower hourly rates and therefore towards brokerage consultancy companies. But how does that affect the long term software quality?
To understand that, we have to look at the effective business model of traditional and new consultancy companies. With the word effective, I mean what happens in the real and not what people say.
effective-business-model
When the business focus is on delivering results, the sales people says “we need to sell more projects” and the technical people responds with “sure, if we work smarter and faster using modern tools and languages, we can complete projects in short time“. On the other hand, if the effective business model is on delivering hours, the sales people says “sell more hours” and the technical people responds “ok, if we introduce more bugs we can stay longer at the same project“.
Of course, nobody ever tell you this, but as a technical consultant you feel this very concrete. For example, the sales people tell you that they have sold you for 1000 hours. Then you ask what you are supposed to do and you get an answer similar to “I don’t know and I don’t care, just sit on your ass the amount of time we have sold you for and try do look busy“.
So, what is the impact of competence development for the single consultant in these two opposing business models?
impact-of-competence-development
Clearly, for hour delivering businesses being a better software developer is counter productive. It is considered a problem if you complete the task in half of the time you have been sold for.
In order to understand how this affect the software quality over time, we need to get familiar with two components. The first is the collective project knowledge, which is composed of both formal (written) documentation and informal (invisible) knowledge. The problems of this are the accuracy of the former and the propagation of the latter. We refer to this as project knowledge transfer. However, knowledge transfer takes time and therefore steals time and concentration from software development.
The second component is the draining vs. contribution time for a single project member. Every new member need to acquire the collective project knowledge in order to contribute to project. Before that happens, the person is draining the project instead, measured in time and cost.
project-contribution-curve
The draining time is always a positve non-negative number and is affected by the amount of invisble but necessary project knowledge. However, knowledge-level, experience and professional seniority is reversely proportional to the draining time.
What happens is that for a long term project, which typically is the case for large organizations, and if the staff turnover rate is too high, the average contribution time becomes too low. If the non-contribution period starts to take a significant portion of the project time, the project is gradually loosing its collective knowledge. At the end, “nobody has a clue“.
accumulated-project-knowledge
The sad fact is that individuals and organizations has opposing ambitions, both trying to get more bang for the bucks.
opposing-ambitions
In one direction goes the technological evolution with higher abstraction levels and more involvment required and therefore higher competence required. In the opposite direction goes, the organizational evolution with standardization and policies which requires low involment and therefore the tendency to completely ignore the competency level.
The net effect, can we all read abount in the news papers; a never ending series of failed software projects.
You can view the whole slide deck at SlideShare
Seminars in Cloud Computing and Groovy&Grails
Today I gave two seminars (2 hours each) in Stockholm. The first, before lunch, was about Cloud Computing and the second, after lunch, was an gentle introduction to Groovy and Grails.
Here a the slides PDF (in Swedish)
I will repeat these seminars in Gothenburg on Thursday.
Tomorrow (Wednesday) I will give a company internal seminar regarding trends in software development.
-
Jens Riboe
