Startups – no place for software engineers?

This post is inspired by http://vampwillow.wordpress.com/2012/07/05/startups-no-place-for-software-engineers/.

The post observes that startup businesses value getting something out, anything out fast is more important in the early days than maintainability. Which competes with the majority of our software engineering training and is thus a poor environment to practice and hone our skills.

Having worked in a few start ups, as well as range of other companies from small to corporation; I too have asked the same questions. However while I see wisdom in some of the conclusions, that post and other posts such as The Hustlers Manifesto sadden me.

As software engineers working for a business, we need to deliver solutions that help make the business a success (hopefully stating the obvious here, but stay with me). The skill in doing this is to deliver both what is asked for, and what is not. We are experts in technology and we are expected to also be experts in delivery of technology. That requires aligning that delivery, while keeping both costs and timescales down. That takes real skill. Learning to transition a project with a changing business is an important skill, that I would argue can only really be learnt by working in a range of environments; and that includes a startup style environment or three.

A neat tool for detecting Memory Leaks from within a Unit Test (Java)

On the train back from work today I crafted an implementation of a HashWheel (a very cool algorithm for scheduling work), and while planning my unit tests I wanted to know that when a task had fired or been cancelled that the HashWheel released the job. Ala no memory leak. So I knocked up the following few lines that I thought were cool enough to share. The best bit was; it found a memory leak that I had missed straight away! Result! :)

I also added it to a github repository where you can find the full source code, take a look at TestTools.java under the public github repository threadtesting-mosaic.


The tool waits for up to three seconds (usually less than 40 milliseconds on my laptop; if it is going to pass that is) before throwing an exception.

To use the tool, just instantiate WeakReference and call TestTools.spinUntilReleased( ref ).

    public static void spinUntilReleased( final Reference ref ) {
        Runtime.getRuntime().gc();

        spinUntilTrue( new Predicate() {
            public boolean eval() {
                return ref.get() == null;
            }
        });
    }

Here is an example unit test that makes use of this tool:

    @Test
    public void scheduleTask_cancelViaTicketAndLetGoOfTask_expectTaskToBeGCd() {
        MyTask task1 = new MyTask();

        HashWheel.Ticket ticket = hashWheel.register( 120, task1 );
        ticket.cancel();

        final Reference ref = new WeakReference(task1 );
        task1 = null;

        TestTools.spinUntilReleased( ref );
    }

For completeness, here is the implementation of spinUntilTrue. Which can also be found in the threadtesting-mosaic repository.

    public static void spinUntilTrue( Predicate predicate ) {
        spinUntilTrue( 3000, predicate );
    }

    public static void spinUntilTrue( long timeoutMillis, Predicate predicate ) {
        long startMillis = System.currentTimeMillis();

        while ( !predicate.eval() ) {
            long durationMillis = System.currentTimeMillis() - startMillis;

            if ( durationMillis > timeoutMillis ) {
                throw new IllegalStateException( "Timeout" );
            }

            Thread.yield();
        }
    }

GitHub Work Culture (people change jobs because of burn out, how to prevent burn out while still working hard?)

A colleague pointed me at this little meme: http://vimeo.com/43676958

Most company work spaces would destroy what they have to say as dangerous, claiming that it would never work.  The interesting thing is that it does work for GitHub, and it works very well.

For me it reminds me of something a very good manager once taught me; the role of a manager is to create and protect the environment and culture for productive software development. It only takes one manager to ignore that advise to damage or destroy the soul of a work place and GitHub has pushed back hard against that decay in thought provoking ways.

Zeebox nominated for T3 Best App of the Year award

If you have been enjoying zeebox this year, then please vote for us in the T3 awards. To do so, just click  here.

Java Modulo vs Bitmask benchmarks

We all like things to run fast. A well known optimisation for ring buffers, consistent hashes and hash tables alike is to replace the modulo operator with a bitmask. The trick being to keep the length of the arrays to being a power of two. Thus replacing a costly operation with a much cheaper one. The question that I wanted to answer here is not whether this optimisation works, but on the Java stack how much of a difference does it make. The following timings were taken running JDK 1.6.0_31 on a 2GHz hyper threaded quad core MacBook, which repeated each operation from cold ten million times each. The table shows that so long as the array length is a multiple of two then hotspot will eventually replace % with & making this optimisation only worth applying to speed up the pre-optimisation window. It also shows that the speed up is roughly a factor of three.

	Min (ms)	Max (ms)	Per Iteration
v % 5	174.812	273.81	1.5ns
v % 4	68.684	127.508	0.6ns before hotspot, 0.4ns after
v & 3	64.45	89.134	0.4ns

Conclusion: When using % n, aim to have n to a power of two. This gave a threefold performance improvement within this benchmark.  The interesting result here is that Hotspot is capable of optimising the modulo operator, rewriting it to a bitmask for us on the fly so long as the division is to the power of two.

Appendium (May 2013): Over the last year I have learnt more about how Intel CPUs are structured, and a few interesting facts have emerged. Firstly a divide instruction takes approximately 80 CPU cycles to execute (ouch!) and can be pipelined at the throughput rate of 20-30 cycles. This is compared to a logical AND which takes 1 cycle to execute, and has a throughput of 0.5.  It also turns out that only one of the CPU ports is capable of performing division but multiple are capable of bitmasks.  Thus using a bitmask is not only much faster than division but more of them may be run in parallel too.   CPU time taken from x86 Optimisation guide (checkout table C-16 in the appendices).  This level of parallelism was not seen in this microbenchmark because the instructions were all modifying the same data.  Also note that this benchmark focused on measuring throughput interlaced with additions and for loop iteration rather than instruction latency; thus hiding some of the cost of performing a division.

View the benchmark code

Using Spin Locks to simplify unit testing of async code

A common barrier to working with concurrent code is having confidence in it. It can be difficult to unit test. The most common solution is to generate events that the unit test can hook in to. However that adds complexity and sometimes it is either too difficult, muddy or just not desirable. In those cases a simpler tool is the good old spin lock. Below is a Scala wrapper around the JUnit assertEquals method that keeps retrying a condition until it is true. If that condition is not true within n milliseconds then the test fails. Simple, but effective.

  def assertEqualsWithRetry[T]( expected:T, actual: => T, maxDurationMillis:Int=5000 ) {
    val startMillis    = System.currentTimeMillis()
    def durationMillis = System.currentTimeMillis() - startMillis

    while ( durationMillis < maxDurationMillis && expected != actual ) {
      Thread.`yield`()
    }

    assertEquals( expected, actual )
  }