“Leaving out the best bit” project management anti-pattern

When I was at university in the 90s, studying computer science, my final-year bachelor project was a "fractal raytracer".

My idea was to write a program which could produce pictures of those wonderful artificial worlds one saw on posters of the time, hung in every university dorm room. Raytracers render highly realistic images, and fractals produce interesting shapes to render.

I set about designing the program, with all the features I wanted. In the object-oriented language of the day (Objective-C) I envisaged a Shape class with various subclasses to represent the various objects the program should be able to render: spheres, fractal landscapes, etc. The fractal landscapes would be further subdivided into those more random mountainous landscapes and, the crowning glory, a 3-dimensional landscape based on those particularly recognizable fractal shapes such as the Mandelbrot.

After the design was completed, I set about the implementation. There was the basic algorithm of the ray-tracer to implement. I wrote a small custom DSL programming language based on TCL to allow the user to programatically specify scenes based on the Shapes available. The rendering of landscapes was quite a challenge especially in terms of performance: landscapes were composed of tiny triangles, and to calculate which of them should be displayed per pixel in reasonable time required a more fancy algorithm than just iterating over all of them per pixel: I envisaged an appropriately fancy algorithm then programmed it successfully.

So far so good, but then disaster struck: I ran out of time. The only hope of delivering something by the deadline was reducing functionality somehow. But what could I leave out? I couldn't create landscapes in memory and have no way to render them, such a program would produce no output and thus look like it didn't do anything at all, so I needed the raytracing algorithm. I couldn't just program the part to generate Mandelbrot landscapes but leave out the fancy algorithm to convert their triangles to pixels, so I needed the fancy algorithm.

So in the end I left out the small piece of code to generate the Mandelbrot landscapes. But i had all the supporting software which would be required for the result of that small piece of code to be rendered.

Y U no Mandelbrot? (image produced by my bachelor project)

So what I had I achieved?

I think this is often the way with software:

Alas I don't know what the solution to this problem is.

It's a bit like spending two hours preparing a curry but then saving 20 seconds by not adding salt, so the result doesn't actually taste nice.

I think one should bear in mind that if one makes cuts to software, due to the fact one can only realistically cut the "crowning glory" features, one is often cutting 5% of the effort but cutting the main purpose of the software, which is a poor trade-off.

Cutting pointless features

A seeming counter-example to the above, from my professional career, is when a product manager, with little understanding of the costs required to produce software, and little self-restraint, insists on a dizzying array of features that the user "might need" and without which they believe they "cannot ship".

Cutting such features definitely helps the product, making it easier for the users to find the features they do actually need, without having to wade through said dizzying array of features they do not need. (In addition to allowing the users to continue to use the product at all, due to the company producing it not yet being bankrupt.)

Nevertheless, cutting a feature such as "users see feeds of their activities and their friends' activities" allows for a great number of supporting elements to be cut as well, for example modelling which activities a user has done or which friends a user has.

So I'd argue cutting features, before implementation has begun (leading to a cleaner user-interface and longer-lived company), is good, vs. simply running out of time and leaving out the crowning-glory feature (for which all the supporting work has been done) is bad.

This article is © Adrian Smith.
It was originally published on 30 May 2015
More on: Project Management