Recently I was reading an old blog post I came across about productivity variations among software developers, where he says that “researchers have found 10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries“. My immediate instinct as I was reading it was that it makes perfect sense, and it’s supported by my own experience, and from what I hear from others in the software industry.

But at the end of the post, he talks about a study which compares productivity of the teams for Excel and Lotus, and makes between their productivity in lines of code:

 Excel’s team produced about 13,000 lines of code per staff year. Lotus’s team produced 1,500 lines of code per staff year. 

It’s interesting the huge difference in lines of code per staff-year, but is that really a measure of productivity? It’s not clear from the post whether a high LOC-per-year is considered high or low productivity, but it seems to mean high productivity in this context. If this is so, then I am probably the least productive person in my team. I make an effort to write as few lines of code as possible.

In fact for the last few months my average LOC per day is probably negative, if you count deletion of lines as negative lines produced¹. That sounds terrible, but it’s because I not only try to write as few lines as possible, but I also simplify other people’s verbose code as I go through it. It’s not uncommon for me to rewrite existing code using 5 or 10 times fewer lines (typically simpler lines).

Let me clarify though. Writing fewer lines of code is not my goal, it’s a side effect. What I try to do is write simpler code. Code that’s easier to reason about. Code that’s more pleasant to maintain. Code that has fewer bugs just because it’s simpler. What generally results from this is fewer lines of code. I do consider fewer lines of code to be a goal, but only in service of readability.

Leverage

Another reason why fewer lines of code can be a good sign, is when you consider how much leverage each line of code has. I don’t know if leverage is the right word here, so let me explain. What I mean is simply a small piece of code that has a big effect, because of some amplification mechanism. For example, a bad coder might repeat almost the same line of code 20 times, while a good coder will instead write a for-loop which amplifies his single line of code to cover 20 cases². A good programmer will use abstractions like this (and polymorphism, generics, frameworks, code generators, DSLs, etc) to amplify small pieces of code to great effects. A good programmer is not one who can write 1000 lines of code, but one who knows how to write 1 line of code in just the right way that it can be reused 1000 times. If he continues to write another 999 lines of this kind of code, he will have produced 1000 times more than the man who wrote the 1000 lines which had only one use³⁴.

This sort of leverage is not linear, because good software engineers can leverage the leverage. They can abstract the abstractions. Any time you find yourself repeating something, you write code to do it for you. The more abstractly you can recognize these patterns, the more generally the solutions will apply and the less code you’ll need to write to get things done (although you have to be careful to not make code more complicated in all the abstraction).

Conclusion

I do understand that getting a quantitative measurement of programming productivity can be incredibly difficult. If it was easy, I could just give potential employers my objective productivity “score” in various areas of expertise, and they could simply hire me according to how this fits their objectives. It would also make it easier to pay software engineers what they’re individually worth. But I think “number of lines of code” is terrible variable to proxy for productivity. Especially when you look at the extremes of the spectrum, where people are really productive or where people get very little done.

This doesn’t change the fact that, at least for me, a better solution is one with fewer lines of code. Every line of code you don’t write is valuable, and often this value outweighs the cost of planning how to not write that line.

1. If you didn’t count deletion as negative, then the best way to be productive is simply to delete and rewrite the same function every day for the rest of your life ↩

2. You might think this is a bad example because nobody would write the non-for-loop code, but it’s exactly the situation I found just the other day ↩

3. It’s difficult to qualify the word “use”, since this doesn’t need to refer to the programmer himself reusing the code, but could also just refer to the number of times it’s executed, like in the example of the for-loop ↩

4. You might think 1000-times reusability is ridiculous, but there are number of places where I’ve achieved this level of “amplification”. They seem to normally manifest themselves as frameworks ↩

Recently I’ve been thinking about what it means for a data structure to support random access (aka “direct access”). This may seem so obvious that it’s not worth thinking about: an array supports “random access” because you can access any element with O(1) complexity by just calculating the elements position and going straight there. A linked list doesn’t have this property because the only way to get to an element is through other elements that it’s linked to. But let’s explorer this idea further.

Here’s one way Wikipedia explains random access quite well:

As a rule the assumption is that each element can be accessed roughly as easily and efficiently as any other, no matter how many elements may be in the set, nor how many coordinates may be available for addressing the data

Let me add another note to this which is perhaps obvious but not normally specified: we’re talking about runtime complexity. If we had a linked list completely defined at compile-time then I would still classify it as a “random access”, even though linked lists are normally not considered to be random access¹.

So what is it about an array gives us random access? Let’s take a guess: it’s because the elements of the array are stored contiguously in memory.

This seems like a reasonable first guess. Because “element 2” is known to be after “element 1” which is after “element 0”, we can calculate where “element 2” is. To get the position of element 2, we multiply the size of an element by 2, and move to that binary position in the array.²

But what if the elements aren’t all the same size?³

If element 1 in the array might be larger than another then we can’t multiply anymore so we need to somehow sequentially access the elements, right? Well, no. If the size of element 1 is known at compile time then we can simply offset this amount when calculating the positions of any element that comes after it.

Perhaps I deceived you when I said all the elements aren’t the same size in this example: I didn’t say whether or not there was static information about the sizes of elements. Lets say that we have an array, which we’ll define such that every second element is 4 bytes big, and every other element is 8 bytes big. To calculate the binary position of an even element in the array we just use `index / 2 * 12 + (start of array)` and to calculate the position of an odd element in the array we just say `index / 2 * 12 + (start of array + 4)` (assuming some implicit integer truncation). These are both constant time operations.

So to sum up, it’s not about whether the array elements are the same size, or how they are laid out in memory. It’s about what we know at compile time vs what calculations needs to be delayed until runtime, and how complicated those runtime calculations need to be. If we go back to our original definitions then this isn’t anything new – it’s just a restatement of our definition of random access. But it does make me think a bit differently about it. 

1. This would be quite difficult to do in most languages. You could do it in C++ with template meta programming ↩

2. Actually it’s not the size of the element that counts, but the pitch of the array – there might be padding bytes between elements to help properly align them. But let’s just imagine the “size” includes the padding between the elements ↩

3. I don’t know any compiler that will generate arrays of elements that don’t all have the same inline value size, but we’re not so much talking about what compilers do as about what could be done ↩

Software architecture theses days is all about separating things. For example, MVC patterns separates the view from the model it represents and code that governs its behavior. Or applications that have a data access layer, a business logic layer, and a presentation layer, to separate different aspects of the application. All these approaches come down separation: for instance you should hypothetically be able to change the way you data is displayed (the presentation or view) without needing to change the model or how the data is accessed.

But how do these approaches actually work in reality? My experience has almost always been the opposite: the more separation there is, the longer it takes to develop. I’ll give you a few examples…

MVVM

A few years ago was doing a project in WPF. If you don’t know, WPF is a Microsoft technology for developing GUIs (or rather, a framework on which GUIs can be developed). It could be said to be the successor of WinForms, and when I was researching it, it certainly looked very attractive.  The underlying architecture it encourages is called MVVM – Model View View-Model, which is similar to MVC. In essence, the “model” is the data in your application, the “view-model” is the data represented in a form that you want presented to the user, and then the view is the actual graphical presentation of this data.

This is great in principle. It means the graphic design team can work on the view and how to present the information to the user in the most flashy way possible, while other teams work on the view-model and model. If there’s some business reason to change the presentation, you can do it without changing anything else. But here’s the catch: all these teams were just… me. It wasn’t such a big project that we needed more than one person working on it, so it was just me. Suddenly all the layers are just things that get in the way. When I need to add piece of data to the model… Now I need to add it to the view-model and view as well, and add all the wiring that connects them. And now we have the same domain object smeared across multiple files.. the xaml file for the view, a view-model C# file, and a model C# file. If the domain changes a little, you need to update all 3 files.

Web Layers

Another example that comes to mind is a website I’m working on. This one is not a one-man project. We have a team of 5 or 10 developers (depending which roles you consider to be part of the actual site development), and the site has hundreds of pages. The architecture chosen for website, when it was started a few years back, is to have separate layers for data access, business logic, business objects, and presentation. In addition to these, there are “layers” underneath the data access layer for stored-procedures and then for tables in the database.

This seems like the perfect situation for a layered architecture. We can have database professionals working on the SQL side of things, and user experience professionals working on the presentation side of things, professional software engineers working on the business logic, and some kind of entity framework or something similar for the data access.

But that’s not what we have. The reality is this: the customer requests a new feature; the feature gets handed off to one of the developers, who implements the tables or fields to store the data, the stored procedures to read the data, the data access layer to call the stored procedures from the web server, the business object layer to represent the objects fetched from the stored procedure, the business logic layer (which is normally almost empty, but gets implemented anyway), and finally the presentation layer so the user can actually see the new data that was added. The end result is about 5 or 10 new or changed files across a few different platforms and whole lot of layers. All for one logical change, like “a customer now needs an address field”.

Is the problem the way work is distributed among developers? Would it be more efficient to have 5 people working on the one logical problem, so each can work on a different layer? No, I don’t think so. Sure, the database would be more efficient, and the presentation layer more presentable. But even with 5 people, the same total work would need to be done, except now you have the extra overhead of coordinating between multiple people on the same logical change – a change that probably evaluates 20 lines of real, business-valued code (smeared across a number of different places). If you can afford the extra inefficiencies, the result might be better, but at an extraordinary price which I would say is only suitable in particularly large corporations.

A successful model

In my mind, the two above examples show how layered development can get in the way of real productivity. The feeling separation “good style” it provides is a lie. But what’s the alternative?

Well, it so happens that I do have a successful alternative. I recently finished re-architecting another project to avoid exactly this problem. To give you some background, the application is a server which mediates between a remote embedded system and a database server (among other things). The original architecture was like the layered one described above: a communications layer, logic layer, and data access layer – each in its neatly separated. If you needed to add some new domain concept you would need to add it to all three layers: the communication layer to be able to transfer it from the embedded system, the logic layer to specify how it should be transferred, and the data layer to interface to the database. Not to mention the extra man-hours spent debugging the connectivity and marshaling between the layers themselves.

So, what was solution? For starters, you should put all your related code together – related by business concept not by activity. You don’t keep “communication” code together – you keep foobar’s communication code in the same place as foobar’s logic and database code. If it was a web application, I would be saying that you shouldn’t universally keep all your JavaScript files together, and all your CSS files together¹. A rule of thumb I would apply is this: If you were to no longer need a particular domain concept (or feature), could you just delete the one file or folder and have it just disappear with no residual or side effects? If so, then the reverse is also true: it’s easy to add a new domain concept without spattering new code across the whole code base (or multiple code bases).²

The second part of the solution is to remove repetition. Since the data “layer” is now really just a hundred mini data layers – one for each separate domain concept – but we don’t want to repeat the same data-accessing code in every file. There are many solutions to this. The one I happened to choose in this case was to write a .NET IL emitter, which at runtime would automatically do a one-step transformation of a C# interface definition into the communications code or database code required. The code behind each “mini-layer” can’t get any smaller – it’s just a single interface, with no explicit implementation.

The result is amazingly maintainable code. All the code related to a single domain feature is consolidated within a single file or handful of related files in a folder, so the process of responding to requests for feature changes or additions generally involved changes to a very isolated part of the code base.

Taking it further

This architecture has proven itself highly successful. The types of maintenance done most often take the least amount of effort, and only ever change or add code in a single isolated subset of the codebase. Also, as much as 90% of new code is actually business logic, rather than boilerplate and wiring code.

It really makes me want to take it to the next level. I mentioned that this project is a mediator between an embedded system and a database. So in effect, the whole application is a “layer” in a larger system. In fact, the web system I was talking about is also a layer – between the database and the end-user. When there is a new domain concept to be added to the system as a whole, they need to be added to all of these super-layers. Why not unify all layers? The embedded C code that relates to a particular domain concept should be physically right next to the SQL that stores it, and the HTML that displays it. If the feature is simple, they could even be all in one file. Static type checking can verify that everything’s compatible.

Each “unit” of code would span multiple platforms and mediums, but hold only a single business concept. Sure, there will be dependencies.. but you can manage these dependencies in the same way that you would have managed dependencies between business concepts in a single layer back when the architecture was layered.

Conclusion

I won’t lie, it would be a difficult goal to achieve to have a fully heterogeneous business units that spans multiple environments and languages. But the problem is not that it’s a bad idea. The problem is just that it goes against the existing way of doing things, and the existing way has a lot of support and tools. Another reason is that the existing system is very good for large teams of highly specialized individuals who can each work on a separate layer, while the “unified layer” system is best for small teams and individuals who have skills in all the different environments that a feature spans. In other words, the big money is behind the layered systems, at the expense of generalists like me who would develop much more efficiently in unified systems.

1. This only applies to files that are tied to a particular domain concept. Of course the styles and scripts that apply globally across the site should be in a common place, such as a “css” and “javascript” directory ↩

2. In the real world there will always be dependencies between domain concepts, but this is largely an orthogonal problem. ↩

This is an idea I have for a feature for a statically typed language which would make the type system more expressive. I call it "mutating types", and in a nutshell the idea is that the act of mutating a variable can also change its type.

I’d like to preface this article by saying that I’ve come up with this idea completely on my own, meaning that if it appears that I’m copying some other academic work it is completely unintentional, and please let me know if I’m doing it. Likewise, please don’t use this idea without acknowledging that it’s mine, and please contact me if you do intend to use it, even if you modify it somewhat.

I apologize in advance for how long this "post" is. I felt it was important to start with the problem description to put the idea into context, and to end with some explanations of how this might be used in practical situations.

The Problem

Let me illustrate the scenario with an example. I’m going to add the feature to C++ in this example. Consider the following types:

struct Int{
    int value;
};

struct Null {
};

struct NullableInt {
    bool isNull;

    union
    {
        Int intValue;
        Null nullValue;
    } value;

    void set(Int i) { value.intValue = i; isNull = false; }
    void reset() { value.nullValue = Null(); isNull = true; }
};

So, a NullableInt is a tagged union which can either hold an integer with a value, or null. I’ve been unnecessarily explicit about the types for Int and Null, because conceptually they are subtypes of NullableInt. Now lets say we have the following code which defines a new Int with a null value, and then calls a function to give it a new value, and then prints out the value that it has.

int main() {
    NullableInt myInt;
    myInt.reset(); // Initialize myInt to null value

    // Call a function to set the value to 42
    setValue(myInt, 42); // function defined below

    // Print out what the value is
    if (!myInt.isNull)
        std::cout << "myInt is " << myInt.value.intValue.value << std::endl;
    else
        std::cout << "myInt is Null" << std::endl;
}

void setValue(NullableInt& i, int newValue) {
    Int newInt;
    newInt.value = newValue;
    i.set(newInt);
}

The function setValue mutates a NullableInt. The particular mutation is just to assign it to a new value, but in general imagine that the mutation might be more complicated.

What I want to point out is on line 9: we have to check whether the value is null or not, even though we know the value isn't null because of the behavior of setValue. Well, obviously we don't need to check the value, and probably most people wouldn't, but there is nothing about the type signature of setValue that says it won't set it to null. In other words if you just assume that it's not null, you're relying on the maintainers of the setValue function to keep that behavior consistent, and not the compiler. This is a reasonable assumption in this case, but perhaps a bad thing to rely on in general.

How would we guarantee, through the type system, that setValue always "outputs" an Int and not a Null?

Option 1: Avoid Mutation

Well, the functional-programming bias in me might suggest the following:

Int setValue(NullableInt& i, int newValue) {
    Int newInt;
    newInt.value = newValue;
    return newInt;
}

In other words, we avoid mutation altogether, and simply calculate a new value based on the old and return it (in this case the new value is not dependent on the old, but in general it could be, which is why I added i as a parameter). The returned value is of the more-specific type Int and not NullableInt, echoing the intention of the function not outputting a nullable value.

This is elegant, but it's not the same thing. For one thing, there are life-time issues. The original value is not destroyed until after the function returns (presumably by the caller), and it's impossible to specify otherwise. In a language with deterministic destruction this is just simply not the same thing, and it has consequences in performance. Quite often, mutations are small changes to a big thing: a state machine changing state, a list acquiring a new item, etc. Creating a whole new "big thing" is just a waste of time¹.

Option 2: Mutating Types

So far I've explained the problem, and also how an immutable style doesn't fix the problem. Now for a real solution, the crux of this post: lets define a mutating type.

I don't know what syntax is best for this, but for the sake of being explicit I'm going to define a mutating parameter type as (T1->T2), where T1 is the type passed into the function, and T2 being the type passed out. It is implied that a mutating parameter type must be pass-by-reference. For example:

void setValue2;
    foo(x);
    foo(x); // err... problem!
}

Here, the fact that foo takes an auto_ptr as a parameter means that it implicitly takes ownership of the pointer. However, the ownership semantics are only a runtime construct in this case, because the compiler doesn't even warn when bar tries to use the value that it just gave away³. But we could rewrite this using mutating types:

void foo((int* -> void) x) {
    cout << *x << endl;
    delete x; 
}

void bar() {
    int* x = new int(42);
    foo(x);
    foo(x); // compiler error: foo expects type `int*` but instead got type `void`.
}

What this example is showing is that the act of passing ownership actually changes the type, so that the type can indicate ownership. Since x is deleted in this case, the new type is void to indicate that the type has no possible values. This not only removes a whole class of possible bugs, but also could potentially improve performance by avoiding unnecessary value-checks.

2. Mutating conditionals

I won't go into too much detail, but imagine that we could eliminate type-casting by instead using mutating conditional statements. That is, if-statements which actually alter the type of their operands.

struct Animal { };

struct Cat : Animal {
    void meow();
}

struct Dog : Animal {
    void bark();
}

void foo(Animal& animal) {
    if (animal is Cat)
        animal.meow(); // the conditional altered the type to `Cat`,
    else if (animal is Dog)
        animal.bark(); // so no type-casting necessary
}

There are some open questions here. For example, what does the is operator look like in this hypothetical language? But you can see possibilities!

3. Once-off subscription/continuation

Here is another situation I run into quite often. In an environment with limited resources you can't always afford to have multiple subscribers to an event. It creates a nice inversion of control to have an event in the first place, instead of a direct function call, but for the sake of performance you aren't going to maintain a dynamic structure to handle the possibility of multiple subscribers because you know there's only one.

typedef void (*Action)(); // Function basic pointer type

struct Event {
    virtual void invoke() = 0;
};

struct UnsubscribedEvent {
    virtual void invoke() { }
};

struct SubscribedEvent : public Event {
    Action _func;

    // Constructor
    SubscribedEvent(Action func) : _func(func) { }

    // Override invoke
    virtual void invoke() { _func(); }
};

void subscribe((UnsubscribedEvent -> SubscribedEvent) event, Action func) {
    delete event;
    event = new SubscribedEvent(func);
}

struct ModuleXStuff
{
    UnsubscribedEvent someEvent;
}    

void initialize()
{
    ModuleXStuff moduleX = initModuleX();
    initModuleY(moduleX.someEvent);
}

void initModuleY((UnsubscribedEvent -> SubscribedEvent) event) {
    subscribe(event, &moduleYsomeEvent);
}

void moduleYsomeEvent() {
    cout << "Some event fired" << end;
}

I won't explain this example too much, since if you've read this far you probably already understand it. The idea is that module Y, whatever that is, needs to subscribe to an event from module X. This is achieved by module X exposing an UnsubscribedEvent, which module Y can mutate into a SubscribedEvent by subscribing to it. Subscribe should actually be a member function of UnsubscribedEvent, but this-mutating member functions is beyond the scope of this post.

The same logic can be applied to continuation functions:

void someLongProcess((UncalledContinuation -> CalledContinuation) onDone) {
    // ...
    // result = ...;
    call(onDone, result); // call the continuation

    call(onDone, result); // Type error, cannot call "CalledContinuation"
}

This is useful if the continuation has some cleanup work to do. If someLongProcess forgets to call the continuation then there will be a type error. And if someLongProcess double-calls the continuation then there will be a type error.

Conclusion

I haven't fully described it here, but mutating types could have a whole host of other uses, and I can't even begin to go into all of them. Most are related to resource and state management, which are particularly important in low level, imperative languages such as C. They are not restricted to "function parameters", although the description of a more general system gets a little complicated to put in a blog. I've only touched the surface, but perhaps I will go deeper in a future post.

Mutating-types embrace the stateful, mutable world that is low-level embedded- or systems-programing. They open up an avenue not just for creating more readable software, but also for making it safer and more performant. I think it would be a great addition to many languages.

1. Of course, I'm all for the idea of writing simple code and having the optimizer recognize where it can reuse memory and so on, but an ideology of C is that we can have more predictable guarantees about performance, and mutation is one way of achieving that ↩

2. NullableInt->Int) i, int newValue) { Int newInt; newInt.value = newValue; i = newInt; } int main() { NullableInt myInt; myInt.reset(); // Initialize myInt to null value // Call a function to set the value to 42 setValue(myInt, 42); // Now, myInt is actually of type Int, and not NullableInt // Print out what the value is std::cout << "myInt is " << myInt.value << std::endl; }

   If you try to interpret the example as straight C++ it may be a little confusing, since Int is not actually a subtype of NullableInt, but this is a different issue. The point is that the function setValue mutates one of it's arguments, and puts restrictions on this mutation by specifying the mutating type.

   Usefulness

   The previous example is pretty contrived. Is this really a useful feature? I'll give you a few examples from real-life where this would be useful.

   1. Resource ownership

   In C++ you can specify pointer ownership using smart pointers. But there's something I've found missing from smart pointers: the ability to specify at compile-time that something acquires or loses ownership.

   void foo(auto_ptr x) {
       cout << *x << endl;
   }
   
   void bar() {
       auto_ptr x(new int(42 ↩
   

3. Note that C++11 move semantics don't really address the problem ↩