I’ve got a few posts planned about AI and HCI, however these require a lot of time to research and write code for, time that I don’t have given I’m flying to the US on the 21st of April. So I apologise to people who saw my last AI article on Hacker News and Reddit and subscribed to my feed expecting more of the same. There will be more, I promise. I just need more time. For now, just some musings.
I’ve been thinking a lot lately about solving problems. I read a number of programming aggregators and startup blogs, and the term “solve a problem” keeps nagging at me. To be successful, at programming and business, you need to solve a problem. I’d love to eventually run a development company, but I don’t know what problem to solve. So, I consider the problem my current employer is solving.
I currently work for a web development company that is doing fairly well. We have a suite of products that we sell to our clients, and sell services related to those products. They’re doing well, so obviously, they must be solving a problem. So, from “client” point of view, the problem we solve is that of letting people who don’t know anything about websites build and run complex websites.
We have a CMS product that allows non web geeks manage websites. This includes writing new pages and editing content on existing pages, publishing news items, distributing these to an email list, managing uploaded files and inserting modules of dynamic content to their hearts desire. The modules we offer include contact forms, random image rotators, resume upload controls, auto-generating bread crumbs and menus, and so on. These modules aim to reduce the complexity of managing dynamic sites, so that ordinary people can do it.
On top of that, we do custom applications built on top of that CMS site. Clients have a site they run themselves with the CMS, but some also have dedicated applications with a separate interface. These are separate because they’re custom jobs. They provide functionality that is not available in the CMS (yet), or functionality that would be too complex to maintain using the CMS. So again, we’re reducing the complexity of running a custom application.
So, on first looks, we build websites and applications that non-geeks can use. But looking further, we manage complexity. We reduce the complexity for the client, so that the client can do difficult things with ease, and don’t have to know how it’s done, only that they can do it.
On the other hand, good programming is about managing complexity. That is, trying to keep your code as free from complexity as you can get away with while still doing the job. Complex code is buggy and unmaintainable.
Complexity exists, and it is immutable. Once you’ve simplified a task to the point that the only steps involved are those that accomplish that task, and that task cannot be accomplished without those steps, you have your complexity, and it isn’t going anywhere. The task cannot be made more simple, because to do that we’d have to leave out steps, which would not accomplish the task.
What we do from then on is delegate complexity, shift it around and make it other people’s problem. Take for example, the task of creating and publishing a blog post. Our software has tagging, categories, post titles and post content. Creating a post involves writing a post, giving it a title, adding tags, selecting categories and publishing it.
Breaking it down, we need to create a body, create a title, create all categories, create all tags, link the tags to the post, link the post to the categories and publish it. Each link has a display name and a URL slug, and each category has a display name and a URL slug. URL slugs cannot contain certain characters, however their display names can.
Now, we can delegate this complexity to the user, which will result in simple code. The user will be responsible for creating tags and categories, and giving them URL slugs that fit our rules, while the application will just take the data and store it, and retrieve it when asked. The user will be responsible for assigning tags to the post and the categories, and the application just stores it. This is obviously an unacceptable level of complexity for the user.
We could also delegate all the complexity to the application, making the user experience simple. The user just types in the tags they want, picks the categories, and the application will link the tags if they exist, create them if they don’t, automatically strip unwanted characters from URL slugs and hide a lot of the complexity. In more complicated cases, this will result in very complex code that will be bug prone.
So the question is, where do we draw the line? What balance of code complexity and user interface complexity is successful? I guess you could say “make it 50/50″ and think that’s good enough, but I don’t agree. I think the balance is very contextual, and often leans in favour of code complexity. In simple examples like above, taking on all the complexity of the task in the code is a trivial thing and easily done. For nuclear reactor control software, things might not be straight forward.
This is the key to a successful software product/business, I think. Finding the right balance between complexity. If you put too much complexity on the user, user’s won’t be able to use it, and your software won’t sell, and the whole thing will bomb. If you put too much complexity on the software, it will be buggy and difficult to maintain, and will eat up development time and money, and possibly even end up costing more than it earns, and then it will bomb. That’s not even including the more personal aspects of programmer job satisfaction and sanity.
Success is finding the sweet spot when balancing complexity.
Tags: complexity, Programming