Finally I found a case, where I really like C# regions: to structure unit tests. Usually there is more than one test per method and finding the place, where the testing of one method starts and the other ends is quite annoying.
In all other classes I still think that the only use of regions is to find which parts of a class should be extracted into a new class 
When switching companies, it is usually hard if not impossible to find out in what culture you will end up. You do the job interview, or today rather multiple instances of interviews, meet the people, show what you have done and what you can do, but usually they will not show what they can do. I wonder why, and have had some nasty surprises in the past. They might show you around the office, demonstrate the table football, show you the Wii and the lounge, but I have never seen that you get to see their source code. Wouldn’t that be even more important?
As software developer, you focus more on the code, the architecture, the tools, the inspiring and ingenious desings around you. So why not demonstrate what a cool company you could be joining by showing you the self-explanative code, the well-founded architecture, the smooth continous build system and how little build breakages are there, for you to work with? I think this tells a lot about your potential future colleagues and their skills, and obviously also whether you will be spending the next months implementing new features or cleaning up their stuff. >> more…
Didn’t know these still existed:
Taken from JavaScript code provided by the leading online marketing automation provider.
Within one week I reviewed two bowling game solutions having lots of interfaces, each of them with only one implementing class. What is the use of that? Being able to enhance it easily? Some leftovers from C++? Did they read it in some books or learn it in university, and if so – who teaches this? Sure, using interfaces even if they only have one implementation is a good thing if you have to provide an API to your code so that others might overwrite your implementations easily… but why do it here? Those interfaces just make it harder to find the part of your code which is actually doing something. >> more…
Refactoring as one of the methods of agile development is part of our everyday practice. It consists in well-defined (often small) changes to the code without altering functionality. One goal is to make the code more clearly saying what it does. Refactoring in this sense is often done while exploring the code before its going to be changed. It shows once more the advantages of bottom up approaches, as small steps are less likely to break the code, while nevertheless in the long run not only leading to better local understandability but to better global structure.
Martin Fowlers “Refactoring: Improving the Design of Existing Code” from about 10 years ago is considered the canonical reference on the topic. And yet with this long history its fun to read, especially if one likes to know exactly whats going on inside those magic refactoring functions from our modern IDEs. All those refactoring methods are shown broken into small steps. By expressing them this way Fowler laid the groundwork for our today’s fancy refactoring tools. >> more…
Being split up into two offices bears some difficulties, espescially because it’s difficult to communicate mainly via email. We try to tackle this problem by having video conferecnes each week, a mailing list to discuss programming topics, interoffice pairing etc., but sometimes it’s good to meet each other in real life. That’s why we have a DevCon (developer’s conference) each year where we talk about collaboration, code and stuff. This time we wanted to focus on clean code and get a common understanding of what we like and don’t like. Because it’s hard to achieve this by merely talking, Christoph and me came up with a coding exercise to be solved in pairs – one guy from St. Petersburg, one from Munich. >> more…
Do you know those books that make you want to grab a computer and start coding – and you only hold off, because there are more interesting things to come?
Those books, that confirm your “I always thought it should be like this” feelings and add a lot of new thoughts and knowledge to that?
Those books you somehow need to tell others about?
This is one of them.
It starts with an overview what Clean Code is and how to achieve it, neglecting not even the simplest things like naming, formatting or comments. I liked the Boys scout rule best which says: “Always check-in the code a little cleaner than you checked it out” (of course, originally it’s about campgrounds). >> more…
Before each release the support guys click through the whole application (following a smoke test script) to prevent that new bugs sneak in. However, sometimes they don’t manage to find all of them. No wonder since humans just tend to make mistakes when doing such stupefying, reoccuring work. Apart from that, the procedure is awfully time consuming – eight days of development require two days of testing.
That’s why we decided to enhance our suite of acceptance tests. Now we use exactly those two days support needs for testing to write new Fitnesse tests. We first created a list of all parts of the smoke test which were not already covered by automated tests. Each pair of developers picks one of the tests, implements it and then the interaction design girls look over it to ensure its quality. That way we already implemented 2/3 of the missing tests. As a side effect we improve old Fitnesse tests we find while searching for “inspiration” for the new ones.
Because Fitnesse tests are run on our continuous build server after each commit, new bugs are found before the smoke test even starts.
And that pays off: In the last three iterations only one small mistake made it into the release! Customers and support love our improved Fitnesse.
Three years ago we closed our old Jira database because it was overflowing with over 1600 bugs and issues and improvements. We had nobody who treated this database as his baby and consequently everybody just dumped stuff into it. Development was regularly critized for not acting on all those requests. For some reason the expectation had been created that this was some sort of queue and eventually everything droped into it would be worked on.
Timo then stepped up, started fresh and has been owning our bug count ever since. He constantly kept an eye on the list and made sure we never were over two to three hundred. Also he regularly interfaced with everybody else in the company to get their priorities as to which issues should be worked on first. But overall the count kept increasing slowly. >> more…
Apple recently announced the next major version of their operation system, called “Snow Leopard”. The interesting thing about it is, that it doesn’t introduce new features, but only changes the technology behind. And it looks like Apple expects people to pay for this. I hope this sets a precedent, like many other innovations from Apple before: Give the developers the time (a whole year!) to improve the technology. And then start to add new things again.
