Tip from Basketball for Software Firms

25 Jun

Many times a software developer’s performance is judged purely on the number of “tasks” that he or she has completed. This can be the number of bug fixes or user stories completed during a given period of time. This would typically co-relate to the amount of code contributed the product by an engineer during this period. Now this is an important metric no doubt.

But in my mind software firms need to pay more attention to an important  non-tangible metric when evaluating a developer’s performance, AssistsI got this idea when watching some highlights of this year’s NBA finals. In basketball, an assist is when a player makes a pass to a teammate that directly results in a goal and points for the team. The number of assists a player makes in basketball is considered an important stat in terms of his performance.

Similarly in software teams, some developers may contribute in many “non-tangible” ways to assist other developers in the team. These can be in the form of architecture/design tips, suggestions for new product features, code improvements or even pointing developers to look at similar implementations in other areas of the same product.

Contributing to the team in such ways is a key trait of a good software engineer and software firms should have mechanisms in place to “quantify” (at least to some degree) such “assists” made by team members. Project/Product managers and even architects can play a key role in helping software firms identify the amount of assists that a developer has contributed during a given period when evaluating her performance. This is by no means an exact science but a “ball park” rating can be very useful.

Software engineers should also realize that their value proposition is not just about writing code but also contributing to the team goal in other non-tangible ways as well.

Look at Steph Curry for example he is not only a huge points scorer but also brilliant in assists, that’s why he is MVP!


Warning: Bootstrap classpath not set in conjunction…

25 Apr

Java or JDKs in particular provide a way of writing your applications to work with older JVMs.

For example you can be using JDK8 for development but you also want to make sure that your code runs in an older Java 7 based JVM. This is done using the “-target” and “-source” switches sent to the Java compiler javac.

So if you want to compile your app using JDK8  but also want to ensure that it works in Java7 you would do something like this.

javac -target 1.7 -source 1.7 <your app src>

Now this will make sure that your application source is not using any Java8 specific language features. For example if your code had used Lambda Expressions the compilation will fail now since they were introduced in Java 8 and are not available in Java 7.

But the problem is although the compiler can check for language features it does not (and most likely cannot) check for the usage of newer API classes introduced in the new Java platform.

So in our example here, if the application code tries to use the new JDK8 specific Date Time API classes, compilation will not fail even though you sent in “target 1.7” and “source 1.7” to the compiler!

And this is why the Java compiler warns you and suggests to set the “bootstrap classpath” to the older JDK specified in your “target” and “source” switches. This ensures that you will not use classes introduced in the the newer JDK.

javac -Xbootclasspath:/path/to/jdk7/rt.jar -target 1.7 -source 1.7 <your app src>

Now if your application code tries to use classes that were introduced in the newer JDK compilation will fail!

Agile is Dead!

12 Feb

Don’t be mislead by the title of this post, this is probably the most important video on Agile you have to watch, by Dave Thomas, one of the authors of the Agile Manifesto.

Mobile is to Desktops what Startups is to Enterprise

9 Feb

Something that caught my attention when trying to understand good Mobile UX was that many of it’s patterns can be applied to larger devices i.e. Desktops as well.

In other words if you start with a Mobile first UX approach you tend to remove the clutter and come up with a more “lean” UX that can be used on desktops as well.

But interestingly (or strangely) I see a similar relationship between how Startups are managed compared to larger enterprises.

Startups are managed in a very lean, less bureaucratic manner with a bias toward action. I think smaller organizational units (e.g. software project teams) within a large enterprise can also take a leaf out of the startup playbook.  This is similar to how Mobile forces a leaner UX design by removing “unnecessary” clutter.

Folks in the enterprise environment may call this Agile but I think having a “Startup mentality” at a large organization is going even more further by shedding as much clutter as possible and getting stuff done.

I guess SAP has already recognized this with it’s AppHaus concept.

Missing ServiceProviders after Shading

4 Dec

Shading is a technique used in Maven to create a single”Uber” jar by merging the contents of  your app jar and all of it’s dependent jars. This makes it easier when distributing your application since there is only one big jar to deal with.

The Java Service Provider pattern is a cool way of building loosely coupled extensible applications.

When building a jar containing such implementations a text file per interface should be created listing all of it’s implementations and placed in META-INF/services. This is used by the JVM when the application needs to load (using ServiceLoader class) implementations of a particular interface without explicitly knowing about them.

The problem is when shading multiple jars containing service providers Maven does not merge the contents of META-INF/services by default.

The solution is to use the transformer ServicesResourceTransformer to tell the Shading plugin to merge the contents of META-INF/services in every jar it shades.

This can be specified in the pom.xml as shown below.

<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>

Edge Case Bias

4 Nov

An interesting thing I have noted when pitching or demoing a software solution to a potential group of end users is something I like to call “Edge Case Bias”.

This is when your users provide feedback considering exceptional use cases that are rare and which usually have simple workarounds.

This sort of feedback usually sounds like “Nice solution! This solution works under the contexts A, B and C but *sometimes* we have situations like Z and this will not work then”

This bias towards edge cases by potential users is quite common but should not be just ignored mainly due to two reasons.

1. The edge case may not be an edge case after all
2. Ignoring the feedback may leave your users with negative feelings

In my mind product management is not just managing the product per se but also “managing” the users of the product.

So when considering the “A,B,C and Z” example above a reasonable approach will be to ask your users to come up with rough numbers indicating the frequency which A, B, C (covered by solution) and Z (not covered by solution) occurs.

Once you get the numbers and find out that “Z” is very rare and has a reasonable workaround you can easily convince the users that changing the solution dramatically to accommodate “Z” is probably not the best way forward.

Of course if “Z” is a high frequency use case then you may have to do some changes to the product. But from what I have experienced in agile development this is seldom the case.

Empathy is a strategic tool

4 Oct

I’ve always felt empathy is an underestimated and underused soft-skill in business environments. I’m pretty sure many people are aware about empathy but people hardly change their mindsets to use it to their advantage.

In software development for example product managers, architects and engineers seldom seem to look at the product from a purely user point of view. During product development this can be done by taking off your “engineering” hat and putting on a “end-user” hat. This is quite important when figuring out your product strategy.

Another key use case of empathy would be in HR management. When making important decisions with regard to employees, managers should put themselves in the shoes of the people who will be affected by such decisions before actually implementing them. I like to call this an “empathetic dry-run” where the manager “plays” the scenario in his/her head not as a manager but as the affected employee.

Empathy is an important tool in business environments which can be easily used in Product Strategy and HR strategy. That’s the reason why modern techniques such as Design Thinking use empathy as a key step in the problem solving process.