Alle Beiträge von Sebastian Kleinschmager

Mein eigenes kleines Entwicklungs-Wertesystem

Ich mache das mit dieser Softwareentwicklung ja schon ein paar Jährchen (irgendwas um die 12 Jahre +/-), und habe dabei wirklich stetig versucht mich zu verbessern. Habe Abends und am Wochenende Blogeinträge und Bücher gelesen, bin zu Konferenzen und Usergroups gegangen oder letztere organisiert, und mich auch ständig mit den neusten Technologien, Praktiken, Methodiken auseinandergesetzt. Dabei baut man sich natürlich so sein eigenes System an Werten und Praktiken, die einen durch den Alltag bringen.

Wenn ich also zusammenfassen müsste, warum ich bestimmte Dinge so tue wie ich sie tue, dann weil ich mir die Strukturierungsmechanismen meiner Software so aussuche, dass diese möglichst auch in mittelgroßen Projekten noch gut skalieren können sollten (was auch immer so genau mittelgroß sein mag). Und was heisst denn skalieren nun schon wieder? Pff! Ok, ich formuliere es anders: Bei der Auswahl dieser Strukturierungsprinzipien gehe ich nach einem denkbar einfachen Modus vor. Ich bewerte Sie nach Ihrem Einfluss auf drei Eigenschaften von Software bzw. Quellcode, denen ich möglichst alles andere unterordne. Diese Eigenschaften sind Lesbarkeit, Testbarkeit und Einfachheit. Aus diesen kann man je nach Argumentation andere Eigenschaften wie Wartbarkeit, Änderbarkeit etc. ableiten. Denn es geht ja vor allem darum, möglichst schnell Produktivität oder andere Werte für ein Geschäft zu schaffen, und flexibel (agil blabla) auf sich ändernde Rahmenbedingungen reagieren zu können. Dabei hilft es mir, diese Eigenschaften in den Vordergrund zu stellen.

OK, bis hierhin soweit klar? Vermutlich nicht, oder? Denn: Hier haben wir nämlich schon wieder sofort das Problem, dass diese drei Eigenschaften sich nur begrenzt messen und in feste Regelwerke pressen lassen. Dazu könnte man eine größere Diskussion zu Messbarkeit von Software und dem Mangel an empirischer Forschung dazu lostreten. Lasse ich in diesem Fall aber lieber. Da mir die Grenzen des Wissens in unserer jungen Branche bewusst sind, habe ich für mich ein paar Daumenregeln entwickelt, um zumindest Testbarkeit und Einfachheit einzuschätzen.

Einfachheit

Beginnen wir mit letzterer, der Einfachheit: Ich sage öfter halb scherzhaft, halb ernst gemeint, dass mein Gehirn zu klein wäre, um große Codestücke wie lange Klassen oder Methoden zu erfassen und zu durchdringen, und ich in Ermangelung von genug geistiger Kapazität meine Code-Elemente daher klein strukturieren muss. Klein heißt für mich: Eine Klasse passt im besten Fall auf maximal 2-3 Bildschirme, was bei aktuellen Bildschirm- und Schriftgrößen auf ca. 100-150 Zeilen Code hinausläuft. Das ist meine Definition von Einfachheit oder Übersichtlichkeit. Dadurch sind diese Klassen und ihre Methoden auch meist auf genau einen bestimmten Zweck zugeschnitten, was schönen Dingen wie dem Single Responsibility Principle Rechnung trägt und häufig auch der Lesbarkeit zuträglich ist.

Lesbarkeit

Lesbarkeit kann ich persönlich selbst mit Daumenregeln nicht mal im Ansatz messen. Ich bin ein großer Freund von Clean Code Methodiken und SOLID Prinzipien etc., aber eine Messbarkeit sehe ich da bis heute nicht. Also falle ich auf Einfachheit als grob überschlagbar messbares Kriterium zurück, und versuche dennoch Clean Code Praktiken und andere Dinge anzuwenden, um der restlichen Unsicherheit noch weiter entgegen zu treten.

Testbarkeit

Kommen wir zur Testbarkeit, die vermutlich einzige wirklich messbare dieser drei Eigenschaften von Software. Messbar warum? Nunja, indirekt. Man kann Testbarkeit natürlich nicht auf einer Skala von 1-10 abtragen. Was man allerdings messen kann, ist die Testabdeckung (Code Coverage) der eigenen Software. Hier peile ich in allen Projekten 90-100% an. Nicht immer 100%, da bestimmte Teile von UI Code oder durch Tools erzeugtem Code entweder nicht, oder nur durch hohen Aufwand zu testen sind. Natürlich kann man die 100% dann trotzdem erreichen, indem man diese Code-Teile von der Coverage-Analyse ausschließt. Hier muss man aber mit Augenmaß vorgehen, um nicht zu viel auszuschließen oder grob zu betrügen. Im Zweifel also lieber nicht tun. Beim Testen ist mir grundsätzlich auch egal, ob das nun durch Unit Tests oder Integration Tests stattfindet. Mir ist wichtiger, dass die Tests eine hohe Aussagekraft über die Funktionsweise der Software haben. D.h. oft nehme ich die Datenbank explizit mit in die Tests, um Fehler in Treiber, Query Engine, Constraints, oder ähnliches auch schon in meinen automatisierten Tests zu bemerken. Geil, oder? OK, nächster Bonuspunkt: Software sollte gewissen Strukturierungsprinzipen folgen, um möglichst einfach testbar zu sein. Lose Kopplung, Abstraktion (Interfaces usw.), kleine Klassen mit genau definierten Aufgaben, etc. So unterstützt die Eigenschaft Testbarkeit auch sofort die Verbesserung der inneren Struktur einer Software. Nun mögen die Klugscheißer unter uns natürlich anmerken, dass man mit hohem Aufwand auch eine schlecht strukturierte Software durchaus testen kann. Das stimmt, selbst solche Software lässt sich von aussen mit UI- oder End-to-End-Test Tools testen, und teilweise sogar eine messbare Testabdeckung erzeugen. Aber meist steht der Aufwand in keinem guten Verhältnis. D.h. man sollte bei der Bewertung der Testbarkeit die Relation dazu nehmen, wieviel Zeit man für das Schreiben von Tests aufwendet, im Vergleich zu der Zeit die man mit dem Schreiben des zu testenden Codes verbringt. Meiner Erfahrung nach, ist ein gutes Verhältnis 2:1, d.h. ich verbringe zwei Drittel der Zeit mit dem Schreiben von Tests, und ein Drittel der Zeit mit dem Code der getestet wird. Das ist ein einigermaßen gesundes Verhältnis, wie ich finde. Und meine Erfahrung lehrt mich, dass das Schreiben von UI oder End-to-End Tests für schlecht strukturiere Software in den allermeisten Fällen massiv mehr Zeit verschlingt, als der Bau der zu testenden Funktion.

Fazit

So, das ist es. Mein eigenes Mini-Wertesystem, welches mich mit einigermaßem gesundem Verstand durch viele Projekte gebracht hat. Diskutiert gerne auf Twitter (https://twitter.com/schmagahimself) oder sonstwo mit mir darüber, bin gespannt.

Schmaga at the German Imagine Cup Finals and the MS Community Open Day

It is time again this week. The national finals of the Microsoft Imagine Cup are going down. The cup is a technology contest for students. It is divided into categories (this year it’s Games, Innovation and World Citizenship) and in each category three German teams compete against each other. There has already been a preliminary selection during regional Finals. The winner teams of each category will be able to participate in the world’s international finals in Seattle and will also receive a few other rewards. And in Seattle even more honor and fame may wait for them. Because the competition there has a high degree of visibility to certain people like investors, supporters and other interested parties. I am emotionally connected to the Image cup as well, because me and some friends competed in 2009 and reached second place in the national finals. Including a handshake with the German minister of development 😉

But this time will be special in one certain aspect, because I will be part of the Jury for the Games competition 😉 I have to be honest: I am a little nervous. I have never been on a Jury in a contest of any kind. People who know me also know me as a passionate gamer who has literally consumed hundreds of games in his lifetime. That’s why I will try to do my best to be an objective and fair judge. After having a first look on the three competing teams I can say: It’s going to be exciting for sure.

The award ceremony will be on Friday during the opening of the Microsoft Community Open Day (COD), which I will attend in my role as .NET Usergroup lead in Essen. During the COD many Usergroup leads, most valuable professionals and other people from the Microsoft Community gather to discuss, network and see interesting talks. I am exciting about that as well and looking forward to meet old and new faces.

(0)

On good developers…

Last November I attended the Clean Code Days in Munich and gave a talk about how discontent I was with many developers in Germany who I met or had to work with during my past career. But that was a rather pessimistic approach to look at the world. So in today’s post I will reverse that point of view and write about what I think it means to be a good developer and what it takes to become one.

Developers I am friends with, my growing network, and especially my work in the Microsoft Community have led me to meet quite a number of developers whom I would deem as committed and talented on an above-average level. Of course during those meetings you regularly ask yourself how to rate yourself among all those developers. In order to rate myself somehow, I spent quite a lot of time thinking about what distinguishes an average developer, a good developer, and the exceptional ones as well.

There are a few skills/abilities that I noticed are essential in that context, and which seem to be especially well-developed by those types of developers I am talking about. Among those are:

  • A readiness of mind. The better a developer is, the quicker he will be in my opinion if he has to delve into new topics and technologies. This also applies to non-technical domains.
  • The ability to abstract from details and focus on them when necessary. And especially to switch between these two modes.
  • A broad spectrum of knowledge. Good developers look past their own field and strive to expand their horizon. They like to learn new technologies and have possibly mastered multiple platforms and languages. They know their way around networks and protocols and might as well have had a look into hardware-related and embedded stuff.
  • A good general education and various interests that go beyond their own line of business. Many of the good developers I had the honor of meeting have a wide range of hobbies and interests. Some are active musicians, other work in social projects, do sports, etc. They keep up to date on the latest news in the world, are politically informed and can in general be called good citizens.
  • They love their job, are committed above-average and work a lot. Especially the freelance-developers I know are not working 40-hour weeks. Almost all of them work much more, as they do not perceive their work as stress or a strain. On the contrary, they love it. They consume Blog-posts, videos and other content about software development and beyond. They test and comment on that knowledge and further develop it and pass it on in their own blog posts. Spontaneous coding sessions in the middle of the night because of a cool idea are not a rarity among this group. As are weekends full of work.

My first impression of these skills is that they seem to be mutually dependent. He who enjoys his job and gets credit for it (and I assume most developers do, at least financially) will probably put a lot more time and passion into it. A committed person like this will probably excel in any job, no matter the line of business (may it be software development or law). At least that thought makes sense to me. But for software developers there seems to be that already described deep intrinsic motivation. There is a drive behind this that I rarely see in other people I know which work in different jobs and businesses that is not software development. But that may be because in my job and life I do meet a lot of software developers which might bias me a bit.

To summarize, it all boils down to three things: A quick and open mind that shows interests in new things, a regular look past the own work and daily routine and last but not least a strong identification with the own work that exceeds the day-to-day job approach. Letting that sink in you can’t help but notice: Almost none of these correspond primarily to hard technical knowledge. It is mostly soft skills… Does that surprise anyone? Not me.

Should this conclusion contain any truth apart from my personal opinion, then this can be taken as a reason to act on: Put more emphasis on the points I mentioned during education, training, and hiring. Maybe there should be better testing to assess potential students of Computer Science and Software Engineering. This could reduce the rate of of drop outs from studies and exam failures. To all developers and developers-to-be: I cannot stress this point enough. It really pays off to try to learn, train and develop all those things I mentioned. There was a point during my studies where it came to me that this should be the way to go. After that it was a long and painful process of learning. But it pays off, believe me!

The German Clean Code Initiative has a good website as a starting point. It has a lot of info and also references to literature and exercises. Sadly it is only available in German. For all you English speaking people out there, try starting by reading the Books „Clean Code“ and its follow-up „The Clean Coder“ by Robert C. Martin. Those are great to reflect on your own practices and hopefully they will point you in the right direction and to additional sources. Enjoy learning!

(15)

Schmaga in wonderland – Re-certification of the MCSD for Web through the 70-494 exam

Some time ago, Microsoft started to implement a re-certification policy for certain certifications, resulting in the need to re-certify every two years. The Microsoft Solution Developer for Web Applications is one of these candidates. As I have owned this certification for quite a while now, I was due for a re-certification.

Well, Microsoft was offering a free second shot, so I took them up on that offer and registered without any preparation. What was there to lose? And I was using many of the technologies in my current projects or have been using them in past projects. That knowledge must count for something, right?

But it was not enough. The evil „FAIL“ appeared at the final screen. It was a close call admittedly, as I must have missed only a single questions judging from the score.

„OK“ I told myself. „That was not too bad considering. I did not study for the exam“. Still, some questions had struck me as totally awkward.

Yesterday I took my second attempt at the exam. This time I prepared more thoroughly by reading both exam books and doing additional research into certain topics. It was a rather intensive preparation. It was enough to *drum roll* ……………. hit the spot exactly at the passing threshold. I probably got one more question right compared to my first attempt. Whoa?! And while I recognized some of the questions, I felt kind of screwed over. I probably couldn’t have answered them if I had had the two books at my side. I cannot go into further detail because of exam NDA, but some questions were even riddled with strange mistakes or inconsistencies (even in the supposedly correct answers). I rarely commented so many questions in an exam. And seriously… memorizing configuration file syntax or configuration step sequence is not a thing my mind considers worth doing. Is that what it takes to be a good solution developer? If that’s what it takes, then I do not want to be one.

I conclude: Working through the books only helps with a few of the covered tops. Either you had previously used exactly the classes/methods/properties that were used in the questions, or you were at a loss. I have never before experienced such a poorly designed exam. And it was probably my tenth Microsoft exam I had the honor to do (or simply had to do, depending on how you see it). Maybe Microsoft should implement an „I am feeling lucky “ button into its exams.

My first year as a freelancer – finally finished my website

Hello world.

Initially, I had planned to launch this new website at the first of May, celebrating the completion of my first year as a freelancer. Of course this did not work out as planned (why did I bother to plan in the first place?) because I was tied up in projects. Anyway, here we are.

In the future, I will try to write some technical blog posts, hoping to share some of my insights from everyday work while solving stuff in my projects or free time.

Feel free to give me feedback about the site.

Greetings,
Schmaga