Software and complexity

Over the past few weeks, I have been conducting interviews for the position of a software developer. I must have conducted more than a score of interviews of people with about 1 to 4 years of experience in the industry. Many can’t answer what the size of an integer is or what the largest representable integer value with a given number of bits is. One person said he couldn’t recall the formula. Of those who get past that, not one person so far has been able to write a 10 line function with confidence. And this is after some initial filters applied by the HR agency that supplies us with resumes – a minimum salary and some development experience. These people have salaries in the range of 3 to 6 lacs. Somehow the industry is able to extract a commensurate amount of value from them.

The product that we develop has over 200,000 lines of code. How will someone who finds it difficult to write a 10 line function work on a codebase of this size? And yet, 200,000 lines of code would be classified as a small to medium project. There are so many software solutions that have millions of lines of code. Presumably these solutions are being maintained by people with the same levels of skills/abilities as the ones I have been interviewing.

The only way I can make sense of this is to hypothesize that the people who wrote those solutions with multi-million lines of code designed them to be maintained by people far below their own levels of ability. That is an aspect of programming that I have never paid sufficient attention to. I have always worried about how to make my code flexible in terms of the requirements it can support and scalable in the data it can handle. My consideration has always been how to minimize my effort when requirements change and load increases. Often this has meant an increase in complexity. I have never worried too much about it confident in amy ability to handle the complexity.

As I look to delegate more and more of my work, do I need to consider this additional factor – how do I write code that can be maintained by someone who barely knows programming? I am beginning to believe that the answer to that is yes.

Complexity in Software

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level). If they are, we make the two similar parts into a subroutine — open or closed. In this respect, software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound.

— Frederick P. Brooks

Encountered in a book (warning: large pdf file – 53 MB) found at Mentofacturing

A user interface element should not look like a rendering glitch

Look at the image below and see what you think of the small blue bar above Gmail. It looked like a rendering glitch until I realized that it was meant to indicate that Gmail was the current application and not any of the others linked to in the link bar. Bad design.

How not to design a User Interface

Some time back I discovered that Windows Vista/7 comes with a command line tool named robocopy with some advanced functionality to copy files and mirror folders. Source control usually makes such tools unnecessary, but I thought it might come in useful nevertheless. So I looked for a GUI wrapper and found this! (I can’t be bothered to remember dozens of command line flags)

This is really an insult to the concept of a Graphical User Interface.

Interesting Excerpts from PDC Languages Panel

…the problem is that you know… the pace of innovation is limited by what people can digest, and you cant force things on them too fast, and so you see… some things happen in generations at some level, and it just cannot be otherwise, because you know… you basically need a certain generation of programmers to retire or die off or whatever before you can introduce radically new ideas, because the stage in people’s lives when they really do something completely different passes at some fairly early stage… atleast from my perspective it is a fairly early stage.

…

…so, keeping it simple, is easier when you don’t have to deal with a committee, because the common assumption is that you know… two heads are better than one, but what you actually get when you have multiple heads is not their union but the intersection, and so its what they can all agree on and kind of negotiate around and it doesn’t work well unless there is somebody in charge …
So you don’t want that, you want to strictly adhere to a very uniform… whether it is functional… all the really beautiful languages basically take something to their logical conclusion… whether it is logic or functions or objects and they dont … mongrelize – hybridize doesn’t have quite the edge that I was looking for – but it is very hard and necessarily to do that in the real world under real time constraints… because in a lot of ways mongrels are very resilient and getting the pure solutions not to be very brittle and to address all the burning immediate needs of people takes time and the time usually does not exist

…

The interesting thing is that the actor model is a perfect fit with the object capability model, and again, if you take that seriously you find that you can introduce a particular model of concurrency that has much to recommend it with relatively little conceptual overhead, again because you are still… you are reusing these concepts of isolated things that communicate via message passing, bcause… well, the common thread to all these things, to the modularity, to the security, to the concurrency is… there is no global anything, there is no top level thing that is all knowing, that can synchronize everything, and knows about everything, and has a global namespace and so forth, because this is what actually scales… whether you are doing modularity or concurrency or worried about anything else, because you know there isn’t actually something up there in the universe.. the laws of physics work very well because they are distributed, because there is no shared convenient thing that you can appeal to that will sort it all out and if you program that way it tends to unify a lot of things

— By Gilad Bracha

The full session is available here.

Brilliant analogy

This is perhaps the best introduction to a subject I have seen.

A real-world example of asynchrony

“A waiter’s job is to wait on a table until the patrons have finished their meal.
If you want to serve two tables concurrently, you must hire two waiters.”

From The Visual Basic Team Blog.

Back to “real work”

After a few weeks of near-daily meetings, I got a week of uninterrupted development work and will likely have another one too. How good it feels! Writing code is so much more satisfying than talking and listening. And it feels a lot more productive.

I do realize that writing code is not the only thing that will make a product successful. Client meetings (and several other things) are just as necessary. And yet, writing code seems like real work and everything else just seems like support. I wonder if that is a necessary result of choosing a particular specialization and being passionate about it.