About two years ago I made some plans for my next project. My time on that project is almost over because I'm switching companies. So it is time to review those plans and make new plans for the next project.

Lets start with the review:

Earlier Tests – One reason we didn’t produce as many tests as I would wish today is that we didn’t do TDD. It probably was a correct decission the last time, since it would have been just to much. But this time I will practice TDD as good as I can.

We did lots of TDD in the project and I love it. Its great and although everybody is bitching about the code quality, I think we are way better of then most of the projects I have seen. After all this XKCD cartoon is still valid. So this one is a keeper.

Cleaner Code – One of the first tests I wrote back then was a test to ensure that we don’t have circular dependencies. We succeeded in this, but still parts of the system a pretty tangled. We gonna improve that. Appart from the knowledge I took from Clean Code I’ll plan to use the toxicity metric as an important tool for that.

I spent quite some time trying to improve code, the ability of myself and coworkers to write clean code and that is certainly a good thing. Another keeper. As always there is still lots of room for improvement.

Dependency Injection – We considered using Spring and decided against it, because we already had about 20 libraries we hardly knew in the project. Again at that time it was a reasonable decision. But in the meantime I learned what we could have gained by using Spring. I’ll propose using it, but even when the team declines again, I’ll be able to use the concept in order to improve the code base.

I failed to make this one real. We had to use a framework which among other problems made it hard (impossible?) to use Spring or anything similar in one large part of the project. We used it a little on the back end, but probably had profited if we had used more features of it. But although we really had only a little Spring in our project I learned to hat its XML configuration. What a royal pain in the a***. But I here there are alternatives out there. We'll see.

So on average my resolution worked out well. I was able to follow through with them and it was to the advantage of the project.

So what will I try to improve on the next project?

Less reflection: I really should have put that in the previous resolution. But sometimes it takes time to learn. Reflection is a powerful tool. But it has a tendency to point itself in the general direction of your feet. It breaks refactoring tools. It hides dependencies and after all in 9 out of 10 cases it is just a workaround for missing language features. I doubt I'll convince you with this statement if you aren't already convinced, but the explanation has to wait for another article.

Cleaner Packages: As I have written before I think cyclic dependencies on the package level are evil.  So early on I established a rule that disallowed cyclic dependencies on package level (and also set some other rules regarding package dependencies). The result: We ended up with a package with over 150 classes in it at some point. For about one third of it even my 7 year old son could have told you these classes where in the wrong package. The problem of course was that it was easier to put a class in the wrong package than figuring out how to structure code and packages in a way that made sense and was legal according to the rules. So I guess the next time I'll bring an extra test that checks for the size of the package oh and another check that keeps me informed when somebody changes the limits in these tests. But more important then the technical side is the fact that I'll have to teach why such rules makes sense and how one can obey them. Certainly a valuable lesson to learn.

More Involvement in the Domain Side: One of the biggest problems we have in our current project is our lack of understanding what the user actually needs. We tried to get into contact with the user (which is a difficult thing in an organisation like the one hosting that project). But we largely failed for a long time. On the next project I'll make sure I'll meet the actual users. Lots of them. Often.  And I will learn more about the domain. Promised.

So these are my plans. Obviously I don't know if they work out as planned. But I will try. What are your plans for the next project or the next 12 months in the same project? Where can YO'U improve?