There is no spoon

I sometimes get very annoyed with code I stumble upon. It happens more often these days, when I'm doing for one of my clients a thorough code review, cleanup, low level refactoring and so on.

Today was a special day with this respect. I found something that made me mad, in the most Monthy Pythonesque way.

I found a piece of code similar to this:

for(int i = 0; i < 100; ++i)
{
    SomeEntity entity = 
        new SomeEntity{SomeOtherEntity = someValue};
}

For the people less familiar with the marvelous Microsoft universe, let me explain that we are using Entity Framework, which is a ORM for .NET, developed by Microsoft. So SomeEntity actually corresponds to a table in the database. The entity instances are managed in a special space called a context. As for the constructor, it has this strange form because it initializes properties of the class with some values.

Now, when any decent developer looks at this code, it becomes immediately apparent that the variable entity is a local variable which is not used again. So, it's useless. Right?

Right, but with one catch. It so happens that whenever you set a property based on a relationship between two entities, as in the example, the entity is also saved in the context. Yes, you understood it correctly. It's like doing something like:

Dialog dlg = new Dialog();
dlg.BackgroundColor = Color.White;

and the dialog gets displayed.

The worst thing is that we didn't actually do anything to provoke something like this. This is how it works out of the box.

Disclaimer: it's true that we are using the beta 3 version of the Entity Framework. However, I am not very convinced that the final version will improve on this point...

Sometimes, in one of my Pai Mei moments, I think about introducing an exception called BadProgrammingException. Ideally, such an exception would also call svn blame and record the name of the developer who did the last modification in the code. (This might actually work from the technical point of view, if the project doesn't use branches and merges; or if you use a distributed vcs like bazaar or git).

The BadProgramming exception would be used in some of the following cases:
- on stack overflow
- on null pointer or reference
- on invalid casts
- on any exception thrown from the code that is not documented
- on value out of bounds
- on assert failures

and I'm sure you can think of some examples, too. Ideally, the introduction of such an exception would create more responsibility for the developers, and make them look twice at the code they're writing.

Of course, this is not possible and it won't work because of the human factor. But this idea raises an interesting question:

Should we try to eliminate "developer exceptions" like the above from our frameworks and products? Couldn't we avoid them in some way?

The answer is: Sure we could, and there's one simple way: design by contract. But, for some reason I can't understand, no mainstream programming language has design by contract built-in. But the possiblity exists; check for example the Nice programming language.

Instead, we are condemned to look at the code and search for all kinds of possible developer mistakes, like this one (C# + LINQ):

User u = db.User.Where(p=>p.ID=150).FirstOrDefault();
System.Out.WriteLine(u.Name);

or this one (C#):

Entity entity = someObject as Entity;
System.Out.WriteLine(entity.ID);

or, even worse, this one (C#):

Entity entity = (Entity)someObject;

In languages like C# or Java, the nullable pattern might work much better. Nullable was introduced for value types that should be allowed to be null. For example:

DateTime? dt = someObject as DateTime?;
if(dt.HasValue)
{
    System.Out.WriteLine(dt.Value);
}

(There are many other versions of syntax, including shorter ones.)

The idea is that the compiler will tell you if you try to convert someObject to DateTime instead of DateTime? (shortcut for NullableType<DateTime>). So why couldn't we use the same pattern for all types? Disallow them to be null, and only allow them when the programmer says so.

But this is just the beginning of a would-be-very-lengthy-discussion. Any ideas?

---

Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu

---

I was very busy during the last weeks, and unfortunately my blog has suffered by having less posts than usual. The reasons are partly related to software development.

First of all, I've worked on the offer for trainings. It's almost ready, and will see the light of web in a few days.
The topics covered are various and are presented in a modern, interactive, hands-on format. And I'm not just saying that; we spent countless hours (mostly during the night) thinking what kind of games, workshops or exercises could help presenting the topics in the best way possible.

The topics go from best development practices (e.g. Software design) to programming languages (e.g. Javascript), from software project management (e.g. SCRUM) to specifics related to development (e.g. Application security) and we think that we add to the Romanian trainings pool the pieces that are currently missing. Our goal is to simply take the best we've learned and pass it on, helping people do their software development better and to feel better about it.

Second of all, I am still working on my DSL. It is a fairly complex task, but it turns out that I made the right choice when I decided to work on it in an evolutionary way: Write, Re-write, Refactor. It's still room for improvement, but I'm happy about the code quality and I'm happy that it starts to take shape.

Third of all, I'm still learning more and more about the Linux ways. I'm very happy with the Ubuntus installed on my computers, but I found out yesterday a few more things: prelink, an invaluable tool for making it run faster, and free maps for GPS applications - including Romania. Really cool!

Last, I have to say a few words about the adoption of OOXML as a standard. I can only use my common sense in this problems, and I have mixed feelings. On one hand, OOXML is nowhere near the maturity I would have expected from a standard: it's unnecessarily complex, it's not unitary, it's very difficult if not impossible for another vendor to implement it. On the other hand, maybe it's better that the format is now controlled by a standardization committee. But that's a very long discussion, and I would rather wait for the next developments before making any conclusions.

Well, that's it. See you soon!

This is the name of the latest of Paul Graham's essays. He discusses the differences between a small technology company and a large technology company, and how the necessity for a boss in large companies limits the creativity and creates a large inertial effect on the company.

Whatever the upper limit is, we are clearly not meant to work in groups of several hundred. And yet—for reasons having more to do with technology than human nature—a great many people work for companies with hundreds or thousands of employees.
Companies know groups that large wouldn't work, so they divide themselves into units small enough to work together. But to coordinate these they have to introduce something new: bosses.
[...]
A group of 10 managers is not merely a group of 10 people working together in the usual way. It's really a group of groups. Which means for a group of 10 managers to work together as if they were simply a group of 10 individuals, the group working for each manager would have to work as if they were a single person—the workers and manager would each share only one person's worth of freedom between them.
In practice a group of people never manage to act as if they were one person. But in a large organization divided into groups in this way, the pressure is always in that direction. Each group tries its best to work as if it were the small group of individuals that humans were designed to work in. That was the point of creating it. And when you propagate that constraint, the result is that each person gets freedom of action in inverse proportion to the size of the entire tree.
[...]
The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things. Sales people make much the same pitches every day; support people answer much the same questions; but once you've written a piece of code you don't need to write it again. So a programmer working as programmers are meant to is always making new things. And when you're part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you're going to face resistance when you do something new.

I have felt the exact feelings that Paul Graham describes in his essay when I started to work as a freelancer. I got free, I was able to experiment, to learn new things, I was different. Before, there was always some kind of problem luring in the organizational web of the company. There was always some good and useful idea dying because so many known and unknown factors had to be put in balance. There was always such a small advance, because of so many and so intricate external dependencies. There was always some kind of expectation from the company to do something that it didn't do, something that it couldn't do, because of some structural reasons.

No more. I don't expect from my clients to take part in my career; I'm building it myself. I work with who I choose to work and I work in my way. I pay my trainings, my books, my expenses. And it's really so much more fun and I get so much better results. I know where I'm going, what I want to do, and how I will do it. It's great.

Read Paul Graham's essay, and think about it. He's right.

---

Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu

---

 

I've gathered a few rules that, when followed, increase productivity of code writing.

Rule No. 1: Solve the problem in the simplest way possible

We are often tempted to think of intricate mechanisms that solve a problem. We are often tempted to generalize the problem and prepare for a future that never comes. We often solve another problem or we solve the right problem but in a complicated way.

I can empathize with this. There's a certain beauty to a system where many wheels turn in a perfect way and work together to solve a problem.

The trouble is that a complex system is complex to maintain. What initially seems a simple but powerful generalization, or the use of a beautiful method for solving a problem proves in 99% of the cases to be off target, difficult to understand, non-functional, difficult to modify, difficult to maintain. Therefore, a small "exageration" in coding produces a cascade effect that may live up to the end of the project.

When you think at it this way, you understand why everybody says that the code should solve only the current problem and only in the simplest way possible. There's always time for smarter approaches later (see rule no. 3).

Similar rules: Don't overengineer, Keep It Simple and Stupid

Rule No. 2: Write first, edit later

We have the tendency to think at better ways of solving the problem during coding. Don't do that: separate writing code from making it better.

Programming is creative work. You have to let ideas flow and to put them on screen as soon as they come. But when you do that, don't concentrate on all aspects. For example, error management can be added later. Methods can be extracted from existing code, once it's written. New classes can be created later.

I'm not saying that you shouldn't do any of the above when you write the code. Write whatever you feel natural to write, but avoid getting stuck in boilerplate or code organization issues. Make decisions on the way, as soon as possible, so that you continue to write code uninterrupted.

I've seen this work while writing the parsing code for the DSL I'm developing. If I thought of all the patterns, of the structure of the code a.s.o., it was ready in twice or three times the workload it took me. Sure, I have to revisit the code and refine it, but that's exactly the point.
Good code doesn't get born out of thin air; it is the result of multiple refinements.

So strive first to minimize the time needed for obtaining functional code. Add the bells and whistles later.

Rule No. 3: Refactor periodically

This third rule completes the circle. You solve only the current problem, in the simplest way. You write first, edit later. And you do this on a number of functionalities.

After a while, you realize that you can generalize parts of the code, or that some methods or classes repeat almost identically in different parts of the project. It's refactoring time.

But be careful: Refactoring means modifying the organization of the code without modifying its functionality. You are not allowed to add functionality (maybe only as a by-product). You are not allowed to change the existing functionality. You can do only a number of things: extract method, extract class, move method, simplify code etc. (you can find them all in Martin Fowler's book about refactoring).

And here you are: three rules for writing code better and faster.

---

Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help.
Alexandru Bolboaca-Diaconu

---