I’m freelance software engineer represented by 10x Management.
My niche is writing code that can be easily understood by other programmers.
This is important for projects which involve security, creating frameworks for programmers, developing applications with complex business logic, and keeping long term software maintenance costs low.
Why is clear code important for security? Here’s an example:
One time I was doing software development for a customer and I came across a function in their code that I didn't understand.
So I started to tease it apart. OK, it's... some kind of string manipulation function... and it's calling "eval" and that's really bizarre... and, uh-oh! It's not even escaping the argument to "eval" so it allows for arbitrary code execution...
Which turned out to be a major security hole. The company was running a marketplace between creators and consumers, and had a currency paid out to creators which could be converted into real dollars. So in this case “arbitrary code execution” meant not just allowing an attacker to do whatever they wanted with the system, but also (if not otherwise caught by fraud controls) to directly steal money from the company.
This bug couldn't be found by testing because the trigger was obscure. It could only be found by inspection, by looking at the code.
But inspection, looking at the code, is only fruitful if the engineer can easily understand what they're looking at.
I regularly work with engineers who are more expert in their particular domain than I am. I’ll be working on implementing a security policy, for example, and I’ll ask, “I was wondering, could this be done in this simpler way” and the security expert will say, “no, look, if we do it that way we’d permit this kind of attack”, and I’ll say, “ah, yes, I see”.
My role, when implementing a security policy, is to make sure that the code is clear. Can an engineer, by looking at the code, easily tell whether the code is correctly implementing the policy or not?
With 18 million software developers in the world and overall information technology spending now above 2 trillion dollars, there’s a large market for products and services that help make software developers more productive.
For example, Meteor is developing a framework which dramatically reduces the time needed to build top-quality web apps.
My own contributions are a series of small projects implementing specific enhancements, each freeing up some time for the core team to do other work leading up to the Meteor 1.0 release.
As a framework designed to be built upon and enhanced by other developers (there are already 1,500 packages contributed by the developer community), we have a particular emphasis on code quality. The software must of course work, that is, be interpreted correctly by the computer, but it also needs to be readily understandable by people.
With some software the description of what we want it to do is straightforward (OK, we’ve got a button, and when you press it this happens...) If the implementation turns out to be a bit ornate, well, sure, it could be better, but it doesn’t really matter because another developer can still readily see what’s going on.
Sometimes though what we’re trying to implement is intrinsically complex. We may be implementing a complex protocol, or we need to handle a bunch of special cases to run in different environments, or we’re implementing a process that itself has a lot of different options and alternatives.
Now we don’t want to add any complexity to the implementation if we can help it. It’s worth it to take extra time to make the implementation simple and clear (and yes, it does take more work, sometimes needing some experimentation, to figure out how to express the code concepts clearly). Then a developer working on the code only has to deal with the intrinsic complexity of the application, without having that complexity compounded by extra implementation complexity.
For a long term project typically the initial development costs are typically 10% of the total and the maintenance costs (fixing bugs and implementing needed upgrades) end up being 90%.
In some situations we don’t actually care about maintenance. We might be writing software to do one task and then we’ll be throwing it away. Or we might be in a startup situation or have a deadline where, yes, it will cost more to deal with it later, but it’s more important to get this done now.
When total cost of ownership is important, we want to keep maintenance costs low by writing software that can be easily figured out by the developers working on it.
I like to keep the development process really simple for my customers. Often they’re offloading work to free up time to focus on other things, so the last thing I want to do is turn hiring me into a management task.
We’ll first discuss the work to be done and put together a spec. If it’s within my area of expertise, and I’m confident I can accomplish the work, I’ll prepare a quote for how much it would cost.
The quote is fixed price assuming we don’t run into anything unexpected that’s really serious. It’s like if you take your car into the shop, and you’ll get an estimate for fixing your radiator, and that is in fact how much you will pay to get your radiator. Except if they get into it and call you up and say, “bad news, it turns out your head gasket is blown”. Which is then a different project, at a different price, which you then get to decide whether you want to do or not to do.
This makes some customers nervous because not every detail can be predicted in advance and included in the spec. Yup, that’s true. It doesn’t need to be. I’ve been doing this for a long time and there is always extra work involved to complete the project. You go in to fix the radiator and it turns out the bolts are rusted shut and another part is bent out of shape. On another car the bolts are fine and it’s something else. Eventually you do enough radiators and you get a sense for how long a radiator job takes to do, even if you don’t know precisely in advance which issue you’ll run into.
After I complete the work the next step is for the customer to do a code review. Of course my customer doesn’t have to do a code review if they don’t want to. But it’s a good idea because after all the point is to write code that’s easily understandable. So I ask my customer, “hey, does this look easily understandable to you?”
My customer will usually come back with code review items, tweaks to be made, extra documentation to be added here, a change to the API there. Which is all included in the price. Sometimes we might have two or three rounds of code review, sometimes zero, but most projects are pretty typical and it all averages out.
And the project is done when my customer and I look at the spec and we both agree, “yup, that’s done”.
You may be wondering at this point what about conflicts? What if we don’t agree about what “done” means? This gets back to the spec. It is my responsibility, my job, to look at the spec and see whether I understand what “done” means for my customer. And if I don’t understand, if I’m not entirely clear, if I’m not entirely sure, it’s my job to ask questions. And ultimately, if necessary, to turn down the job if I’m not getting clarity that I understand and can deliver on what my customer wants.
And finally, one of the reasons that I’ve hired 10x Management as my agent is they can help resolve a dispute if needed. Which I certainly don’t anticipate. It’s kind of like wearing a seat belt: I don’t wear a seat belt today expecting to get into an accident today, but I wear a seat belt in case I do. Likewise, I hope never to get into a dispute with a customer, just as I hope never to get into a car accident. But if a dispute does happen 10x is there is help. Yes, I’ve hired 10x, they are my agent, they represent me, they’re “on my side”. But if it comes to that it’s still better for my customer to be able to work with someone who is a professional at business deals than with just me (who is an amateur at business deals).
Email me at [email protected] and we’ll set up a time to talk about your project.