Continuous improvement


I started writing most of this article back in January and did not have time to finish it since – because I was stuck in doing exactly the things that I wanted to avoid. Now it’s time to finish the article so I’ll be able to compare my recent experience to my oh so nobel goals. This is what I wrote:

The week before Christmas was the last week in the office of a customer I have worked for for a little more than two years – which until now is the greater part of my working life. So at the moment I am thinking about the things that I have learned over that time to being able to apply that in my future work. I write this article as a reference to check against when I will look back at it in a few months to identify things that I have been doing different from the way I wanted to do them.

Only recently two interesting thoughts have been stuck with me: The first was an article that has been linked on Hacker news with the title “Everything is my fault” (http://news.ycombinator.com/item?id=4895335). To me, this meant to always remember not to blame anybody else for the things that are not done in the way I like them to be. Instead, in most of the cases it is myself to be blamed for not changing things or convince the right person about it. The other very helpful thought comes from Eric Schmidt in an interview at the Computer History Museum: https://www.youtube.com/watch?v=NfalakTPsnE&t=3m15s “It was some really smart person who really thought this was really good, and maybe I should understand why, before I just willingly attack them without any basis. My architecture by the way was better, but theirs was good too.” To me this basically means: Don’t be a smart ass and respect people around you – and I am still in the process of learning that.

With these premises in mind I’ll now just document my experience of what I believe are important things that I have learned over the past months.

Project management – tools and processes

The most annoying task I had to do repeatedly was time booking. I think this is a widespread problem and most people in bigger companies experience this, but I won’t accept that in the future and will do everything I can to reduce the overhead. In my case there have been some months in the transition between multiple time-booking systems when I had to book every little task into 4 (four!) systems – the work-items (Team Foundation Server), the old management tool (can’t even remember what that was), the new management tool (Microsoft Project) and the system of my employer to write the bill. To keep track of the hours I had already booked, I kept the hours in a fifth system, an Excel sheet as a “master”. This really is not only annoying, but also is a lot of wasted time and money. I understand that it is necessary to keep track of the hours, even down to “workitem/issues” level, but hopefully I’ll be able to keep that simple. We will keep track of the time in an instance of Redmine and import the entries into the proprietary billing system at my employer.

Another issue that is directly related with the tools being used has been, that the project planning has been done in MS Project, while the work-items to be worked on and booked to were created in TFS. Unfortunately Microsoft hasn’t been able to make those systems compatible (at least not that I or the customer know of). This, too, will be done in Redmine in my future projects (or any other good system, but not distributed over multiple databases…).

Setting up a build-server and doing continuous integration with unit-tests is another thing that I plan to do. I believe that the time invested in early stages of a project pays of big time. The same goes for doing reviews on a regular basis!

Project documentation

Documentation has been an important thing at the recent customer. Most of the documentation has been pretty good and I have learned the importance of having a place to look up specifications at a later time. The hardest part of writing good documentation however seems to be to decide what’s important and what’s not. A good part of technical documentation will always be work in progress and therefore it should be as short and formal as possible. Having technical documentation as close to the source code as possible also helps in keeping it up to date. In one project we used Sandcastle as a doc tool, but I don’t like it because it ads great overhead and took a very long time to compile (over 20 minutes). I will have to look for a better solution for my next project. Suggestions?

Having too much documentation might even be hurtful because it will lead to not reading any documentation at all in the future as well as to outdated information.

Requirements are the most important part of the documentation, but obviously it is very hard to phrase them properly.

The craft – technologies and architecture

As a developer, the most interesting part is the technologies and architecture being applied. My main tasks where to develop front ends using WPF and database services using Entity Framework. Additionally, the communication between frontend and backend has been a part of my job. For one project we used WCF, for others, proprietary protocols have been used. Another home-baked protocol has been used for the communication between the different programs and modules. Communication and thread handling is being done in an internal framework that is being used in almost every component.
While that makes sense for the most part, there was a very strong tendency of creating own protocols, patterns and frameworks instead of using existing solutions. The main reason for that was not to be dependent on external development. Sometimes this may be a valid argument, however my opinion is that it is always better to stand on the shoulders of giants – use open-source libraries, use existing commercial solutions, but don’t roll your own!

Testing

Quality assurance was a very important part of the development process at the customer. It was pretty good – the question is how to apply that to other conditions when it is not possible to have a whole department for it.

People and working atmosphere

I have learned about the importance of knowing each other, transparency on both ends, management listening to “the people” instead of making decisions without being grounded. Also: find the right person for the job. (Keep “creative” (but good) developers on a tight (but not too tight) leash, check & follow up.) It’s important to introduce a new colleague into the environment – both, the people and the technical stuff. Not only should a new employee have time to adjust to a new environment but the entire structure should be optimized to be easily understood. This goes on the micro-level with having a software project structure that can be up and running within minutes as well as on the macro-level with processes within the company that should be as simple as possible.

Well, that’s it for now – I’ll keep this article primarily as a reference for myself to compare to future experiences…


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.