Tag Archives: strategy

On The Illusion of Controlling People’s Time

Software Engineering is going through an identity crisis. The old school has failed because of too much control, moving people away from what they really have to deliver. The new school, or agile fever, is more focused on humanities, directing all the attention to human beings. This approach practically decimated the old school, showing that writing software is not an exact science. It is actually unpredictable and cannot be done without creativity, inspiration and transpiration. Maybe the old school, which insists to exist, got confused by the fact that software execution, data processing, and system and hardware design are engineering stuff, but it doesn’t mean that developing those stuff is also engineering. On the contrary… it’s human and social.

When I see managers trying to measure the time spent on people’s daily activities, I understand they are taking into consideration only the transpiration of their teams and completely ignoring the creativity and inspiration. These two last aspects are so subjective that it’s hard to compare their manifestation on different people. How to compare artists? We may find artists’ comparisons out there, but they heavily rely on who is producing the comparison. Let’s ask ourselves: why on earth would someone use quantitative criteria, such as time and money, to measure and compare subjective matters?

Measurements are only useful when we’re capable of making comparisons with them in an objective way. We compare the date of our birth with the calendar to know our age. In times of crisis, we pay attention to our water, gaz and electricity consumption and make comparisons, finding ways to save money. Climate is measured because we need to decide which clothes to wear or which precautions to take by comparing with previous experiences or common sense. Notice we put measured subjects into perspective to understand the real dimension, the scale, the direction, and then we’re able to reason about trends, behaviours, issues, patterns, etc.

When it comes to subjective matters, we might be able to make comparisons, but measurements are just useless in this case. Actually, we can come closer with a lot of statistical methods, multi-variable analysis, multi-criteria craziness, but do we really have time and resources to produce all these analyses in a daily basis, and even take the risk of being probabilistically far from what it’s expected? It sounds complicated, isn’t it? That’s because it is. 🙂

In software development, every activity is different from one another. It’s impracticable to precisely compare two activities even if they look the same and are done by the same person. It’s all subjective, otherwise it would be easy to put the project on schedule by adding more people in the team. We know that since 1975, when Frederick Brooks published “The Mythical Man-Month“. So, when a manager asks their developers to inform the time spent in every activity, he/she is in fact collecting lies (or non-truths). If he/she prepares a report with those collected times, this is going to be the spread of an even bigger lie (or useless information).

But why lies? There are two good explanations for that:

  1. most people don’t track exactly how much time they spent on their activities, thus they actually inform safer figures, which are usually higher than reality;
  2. time control gives a feeling of surveillance, making developers believe their manager wants to know whether they are really working or not, thus they smartly add some extra time to mask non-productive time.

Managers should also be aware that time control also kills creativity. When developers have new ideas, potentially useful for the project, they cannot simply turn them into activities because of scope constraints or just because those ideas are not clear enough to be described. Without activities, developers cannot report their time. Therefore, if they spend too much time working on their ideas, it will look like huge time gaps for their managers.

Eventually, managers are moved to implement time control because of visible procrastination. I remember once when a new project was starting, a big room was allocated to a team of 12 people, and the project manager asked the team to choose their places in the room. There were 15 places available, 12 with monitors facing the wall and 3 with monitors facing the door. Guess which places were left available? That’s right! The three ones facing the door 😀 I remember the symphony of mouse clicks and sudden movements when the manager walked through the room. That was so funny! 😀 But time control wouldn’t solve that problem because inputing time on activities is also a distraction. Anything that is not building deliverables is a distraction. We may never eliminate them, but we can always reduce them. The solution for procrastination, in a single word, is: Motivation!

But, is time control totally out of sense? It has some sense when the work is fully based on time, which is the case of consultants payed hourly. This is about their business model, not software engineering. That’s a good practice for consultants to inform to customers how many hours they had spent because it’s directly related to their payments. Notice that this kind of service is for a short period of time and for highly specialised skills. However, we are talking about software projects that last longer.

Finding ways to motivate your team is the best strategy to put them on track and fully productive. Every form of control that threats their feelings will put them down. Motivation doesn’t need to be monetary or entertaining. Sometimes, it’s enough to show their wins, how important is their work for society, how it changed people’s lives, and why it’s important to keep doing what they’re doing.

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more. For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from on task to another, it changes the mode in which you work. – Paul Graham

The Consequences of Deferring Project Jigsaw

Mr. Mark Reinhold has announced in July 2012 that they were planning to withdraw Project Jigsaw from Java 8 because Jigsaw would delay its release, planned for September 2013 (One year from now). This date is known because Oracle has decided to implement a two years roadmap planning for Java, so September 2013 is actually 2 years after the release of Java 7.

According to Jigsaw’s website…

“The goal of this Project is to design and implement a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. The original goal of this Project was to design and implement a module system focused narrowly upon the goal of modularizing the JDK, and to apply that system to the JDK itself. The growing demand for a truly standard module system for the Java Platform motivated expanding the scope of the Project to produce a module system that can ultimately become a JCP-approved part of the Java SE Platform and also serve the needs of the ME and EE Platforms.”

They also say:

“Jigsaw was originally intended for Java 7 but was deferred to Java 8.”

Now they want to defer it to Java 9 🙁 More details of their decision making are available in a Q&A post on Reinhold’s blog. You may read and follow the discussion there. Here is my opinion:

Without Jigsaw, I believe that it’s very difficult to put Java everywhere. Without Jigsaw, the idea of multi-platform is getting restricted to servers in a age of smartphones and tablets. Jigsaw may be “late for the train”, but it is letting Java late for the entire platform ecosystem.

Deprecated installation screenshot
Observing the market, we can see that development is becoming platform-dependent (iOS, Android, etc.) Only Java can beat this trending because of its large experience on multiplatform implementation, and the time to do it is NOW! Otherwise, in 3 or 4 years there will be no Java on devices, and the development community will have enough knowledge to live with that. Therefore, Java will be basically a server-side technology.

The reasoning behind my prediction is the following: mobile devices are limited in terms of resources and a modular JVM would allow the creation of tailored JVM considering the constraints of each device. I put myself in the shoes of those devices manufacturers: “I wouldn’t distribute something in my products that might impact negatively the user experience in terms of performance”. That was the argument (at least the public one) Apple used to avoid distributing the Flash plugin for iOS’s browser. Probably because of that, Adobe definitively gave up Flash on mobile devices. A modular JVM would simplify a lot Oracle’s negotiation with many device players. It would be reasonable for Apple to include Java as a language for iPad and iPhone applications; Google would finally embed the JVM into Android to evolve faster with new Java language features, getting busy just with a module to extend the JVM to specific Android’s capabilities; it would be even possible to save Nokia from bankruptcy 😀

You may wonder whether Apple and Google would ever adopt JVM as a standard runtime platform. Have you heard about opportunity cost? It states that our current choices and activities are actually blocking other possible choices and activities. The tricky part is to chose the opportunity that is least costly or with the highest profit. Having said that, we can see the scenario considering that Java was not an option because it wasn’t modular when those companies made their decisions. If Java was modular and Apple had adopted it, iOS platform would have at least three times more apps than Android. “Java” was in Google’s strategy to catchup with Apple. Only Java could allow Google to do it in such a short period of time. So, it’s not so simple to ignore Java.

Now, Oracle vs. Google: Of course the effort to move Java forward should be economically viable, and in order to use Java, Google would have to spend some money. Unfortunately, Oracle and Google work with different currencies. While Oracle thinks in terms of licenses, Google thinks in terms of advertising. These currencies are incompatible, very difficult to convert, because while license is cost, advertising is profit. Therefore, Oracle would never reach a deal increasing Google’s cost, but it would be possible to get a deal decreasing Google’s profit. In other words, Oracle could have a percentage of Google’s profit on advertising sold through Java apps in order to make Java available for Android. Google makes this kind of deal with a lot of companies like Yahoo, AOL and others. Why not with Oracle?

If Oracle doesn’t give all resources that the JDK team needs to make Jigsaw a reality in Java 8, Oracle will be completely out of the pervasive game very soon. Without breaking the JDK into manageable and efficient pieces, Oracle won’t have arguments to convince the industry that Java is the way to go on the long run.

Before deciding to drop Jigsaw out, I beg Oracle to think about the consequences! They must ignore the fixed release roadmap and accept the difficulty of the task. We can stay happy with Java 7 (it’s not widely adopted anyway) as long as Jigsaw is on the way to Java 8. This fixed release cycle can actually come back after Java 8.

I would love to be wrong and be taken by surprise with an official Oracle’s announcement of the definitive support for JavaFX on Apple and Android devices during the next JavaOne 😉 However, I think the likelihood is very low 🙁

Creative Solution to Keep Business Running Under Special Circumstances

Rue du Luxembourg, Brussels, around 7:20 in the morning, going to work. A drugstore was under complete renovation. It wouldn’t be open for customers… unless they put the drugstore in a special container and place it on the sidewalk just in front of it 🙂

If you are planning to renew your business, take some time to think about a creative solution to keep it running.

Did Oracle Regret about Kenai Ultimatum?

All Kenai Project Leaders received a message from Oracle trying to explain a possible misunderstanding about the message they transmitted before. From my understanding there is no misunderstanding, but a change of plans due to the community reaction. Take a look at the open letter below:

Gentlepeople,

In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for Kenai.com to you. I would like to remedy that now. Our strategy is simple. We don’t believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community. We are in the process of migrating java.net to the kenai technology. This means that any project currently hosted on kenai.com will be able to continue as you are on java.net. We are still working out the technical details, but the goal is to make this migration as seamless as possible for the current kenai.com projects. So in the meantime I suggest that you stay put on kenai.com and let us work through the details and get back to you later this month.

Thanks for your feedback and patience.

Ted Farrell
Oracle Corporation
Reference: http://blogs.sun.com/projectkenai/entry/the_future_of_kenai_com

That’s pretty good! It is the first signal that Oracle is willing to listen to the community. I’m happy with that because it was a constructive decision, good for both sides. However, a question remains: Will current java.net projects migrate to Kenai infrastructure or will Kenai projects migrate to java.net infrastructure? I’m asking that because the Kenai infrastructure is far better. A migration to java.net infrastructure is actually a downgrade.

It seems we have to wait until the end of February to finally get an answer. I can’t wait for that! 😉

Good Ideas for Kenai That Somebody Else Should be Doing Instead

As you already know, Oracle is planning to deactivate Kenai for community developers. Yes, it is sad but let’s move on and spread our code before it is destroyed. It is also time to make public some ideas I’ve been sharing with Sun’s folks last year. I have criticized Oracle for some decisions they have made, that’s true, but I don’t want to criticize and shut up. I have to propose something better and realistic to show that they are lazy thinkers, growing by buying other people’s innovation, not actually doing their own.

I want to discuss 2 ideas. Each one solves a particular need of entrepreneur developers.

  1. I need integrated services to manage my software project and also to deploy it: It would be a mix of SourceForge with Amazon EC2, or Assembla with Google App Engine. Once my code is committed to the server and an integration test is performed, then my application would be automatically deployed in a server. Today, we need at least two different service providers to make it happen and it means more bureaucracy and waste of time. If Oracle or RedHat adopts something like this, the payment for such services would financially support their open-source projects, such as OpenSolaris, Glassfish, JBoss and MySQL.
  2. I’m an expert in my own open-source product, but I need help with its infrastructure: I have a complex and large JEE5 application and my expertise allows me to provide good support in terms of application features and bug fixing. As a matter of fact, my application is using Glassfish as application server and MySQL as database. However, all I know about these technologies are enough to develop and deploy the application. If a critical error occurs, avoiding the application to run because of an external and unexpected problem, probably my own knowledge is not enough. In order to solve that, Oracle or RedHat would make a partnership with developers, providing services that complements developer’s services. Considering RedHat, the customer would pay directly to them for the services and RedHat would transfer part of the payment to the developer, who provided part of the service too. With this deal, every developer becomes a potential retailer of RedHat’s services. That’s one more solution to increase investments on open-source projects.
Both ideas above were explained to Sun engineers some months ago (At the time I was thinking that IBM would by Sun :D).  To sell open source products, companies should innovate, however Sun was good when innovating their products, but not their selling and services processes. These parts of their business were always traditional. RedHat, on the other hand, has far better selling and services processes for their open source products than Sun because they are agile, have simple procedures and minimal distance between the customer and the specialist. That’s why they are one of the only companies to get profit from open-source.

Companies that already offer software project management (track system, version control, wiki, etc.), such as AtlassianCollabnetGoogle or even Oracle with Kenai, have strategic advantage because they already have something done, with large experience on it. I only wish that people out there get this idea and make it happen. This is not what I love to do, so I won’t appropriately exploit it. But I’m confident that these are good ideas and I hope to blog about any future service that provides such features and I’m probably going to be one of the first customers of the pioneer.