Sunday, December 31, 2006

The "Model Driven" Paradigm in Software Architecture

currently I'm researching the "Model Driven" approaches to software development. Yesterday I discovered some groups on xing discussing model driven architecture and model driven design. After browsing through some of the entries I discovered that the common understanding of model driven approaches seams to be "generate code from some diagram" or "introduce a new domain programming language". In my eyes this boils down to using a new programming language. And yes, I consider diagrams that generate code as yet another programming language.

I usually don't rely on forum discussions as primary source of information, so I wanted to find out more. If you do a google search on "model driven" you get the wikipedia page on model driven architecture and the usual suspects: information from companies that want to sell you their brand new model driven tools. As MDA seems to be a major topic on OO conferences you'll probably agree with me that this may be mostly due to some big bucks behind the movement.

But the concepts behind MDA are not really new. The wiki-page sums up the central statement of the model driven approach as:

One of the main aims of the MDA is to separate design from architecture and realization technologies (...)

This is old stuff. And I don't yet see how using UML models as programming language will solve any issues. The domain language approach is interesting, though. But let me explain my view on this whole architecture thing...

Separating the design from architecture and realization technologies is one of the main concerns of good software design for some time now. Eric Evans for example proposes the "Domain Driven Design" concept, which basically means to take the programming language of your choice (state of the art: object oriented) and create a set of objects with which you can build up a domain language that still follows the implementation rules of the underlying language.

The bad thing is that even on the domain level you are still dependent on the underlying language. But I know from experience that you can even code 95% of your C++ project in a technology agnostic way. This is the real challenge of software architecture: build or buy a technology layer that hides your underlying hardware architecture away and create an easy to access domain layer that nonetheless captures your domain logic.

The good thing about not introducing a new language, be it an UML model or a new domain language, is that, well, you don't need a new language... The key question is: why is UML or a new domain language better suited to the task of describing a domain logic than <pick your favorite OO language>?

Let's consider the options: What about using UML as a programming language? One of the first comments in the xing forum about MDA I found was about "hey, our programmers don't like the clumsy way to express all the complex logic in a UML diagram - can I create one by using a textual description? this would especially make diffing much easier...". This says a lot.

When I wanted to learn UML, I asked my colleges if anybody knew a good introduction into the topic. Andreas than got me some UML reference and handbooks. 1500 pages explaining how to use UML. But that wasn't what I was looking for. I was looking for an explanation of how to use UML in a way that it's actually generating business value. I didn't read those manuals but found "Domain Driven Design" by Eric Evans. Now this is technically not really about UML, but it introduces some very interesting practices regarding it's use.

Eric Evans states that a diagram should be used to communicate a concept. He argues that trying to stuff all the information into a diagram tends to render them useless. This exactly matches my experience. And this is why I don't think UML diagrams (or any graphical representation, for that matter) is a good choice as a programming language.

Now for the domain language. A domain language is a new programming language that enables you to write domain logic in a way that matches the way rules are usually expressed in the problem domain. In my opinion this is often a very good idea. It is used widely since a long time now (perl and the posix shell language started as domain languages) and there are myriads of calculator sized scripting interpreters used in commercial applications. You can probably think of some more...

But there is also some choice with regards to general purpose languages. When implementing a domain language (like php, which was originally developed to be used for dynamic web services) often the feature requests make the language a general purpose language over time (perl, php, bash, just to name a few). At that moment you have a new general purpose language on the market and have to ask yourself if it wouldn't have been easier to use an already stable language in the first place.

At the time of this writing, there are many general purpose languages that target different domain audiences. There are the functional programming languages that express mathematical concepts (while high performance maths is still done in fortran), the logic programming languages that target, well, logics and a bunch of object oriented languages that target web server development, web client scripting, web browser extensibility or just try to provide fine building blocks for object oriented domain frameworks and domain design (like java and C#).

So what should you do if you are an architect. My advice is to look for a nice general purpose language first. If your choice is one of those diagram compilers, than fine. Just make sure programming in this language fits your needs. If you find a framework for your chosen language that makes developing the domain logic easier, use it. Mind that I don't argue against using UML diagram compilers or frameworks or your own little language that you always wanted to implement. But I don't believe UML diagram compilers really enhance your productivity in all but a small limited set of applications. The same goes for elaborate frameworks or the use of awkward domain language wannabes like Gupta.

Most of your domain language needs can be met by today's general purpose languages.

The art is to use the language concepts to implicitly express your domain language. This can be done with every general purpose programming language I know (even with perl - which was built as domain language for string manipulation and "grew" into a full-fledged swiss army knife object oriented programming language and - in my opinion - often into a maintenance nightmare).

So what remains of the "model driven" hype? If you take away the fuss about expensive programming tools you get what Eric Evans calls "Domain Driven Design": Use diagrams that really enhance understanding. Use diagrams only to show few concepts at a time. Use your design skills to make your general purpose programming language feel like a domain language. And finally introduce a new domain language where it really makes sense. Most of all, come down from your ivory tower and get your hands dirty on the project.

Thursday, December 28, 2006

Review: Object-Oriented Metrics In Practice

The book in one sentence


A short, modest and dryly written book with some brilliant new concepts and a lot of too easy solutions which is worth reading because of the brilliant ideas.

Preceding events


How did it come about that I read a book about software metrics? I will have to digress somewhat before answering the question. There is a strong common believe in software engineering that software metrics are a dangerous tool, especially in the hand of Joel's bright young management consultant. But sharp tools that you can use to harm people can often be used to get things done.

What if our pre-pre-pre-(...)-pre-ancestors had condemned the use of a knife just because some of their brethren ran around slitting up other peoples throats? So I wanted to find out more about software metrics to decide for myself if they provide a new, sharp tool, or just a deadly weapon to be utilized by management consultants. But even with a lot of google magic I couldn't find a good critical introduction to software metrics anywhere on the web.

Then a few weeks ago an IT consultant asked about software metrics in a forum about software quality assurance at xing. I answered by reiterating the "dangerous tool" conception, emphasizing that software metrics alone can't be used as a quality assessment, which obviously didn't satisfy our questioner. Another member recommended "Object-Oriented Metrics In Practice", praising especially the solution oriented style of the book. So I figured that I should educate myself on the topic before broadcasting my opinion.

Reading...


The first good point the book makes is that software metrics can show only structural points of interest, but not design problems (unless you find a metric that can measure the semantical aspects of variable and class names, of course). Therefore a software metric can be used to find conspicuous code fragments that must be analyzed by hand to get substantial information. If Joel's consultant had read this book and had understood this concept we wouldn't need to be afraid of him any more.

The brilliant part of this book is the part about metrics visualization. If you ever ran cccc over a > 200kloc project, you know that visualization of metric results is hard. When I used cccc at work to assess our C++ project (before reading this book) I didn't find anything new or exciting in the results. The metrics showed me two or three structural problems that I was already aware of without using any metrics and quite a lot of false positives. After reading the book I came to the conclusion that it was not the metrics that were useless, but the simple brute force manner in which they were applied.

The idea of Lanza and Marinescu is to combine metrics in a way that answers specific questions about the code and visualize the results in a way that makes it easy for human beings to browse through the structure and especially to visualize the structure in combination with the metric results. If you want to learn more about how you can utilize metrics efficiently and how much work you have to invest to be able to use metrics at all, I highly recommend this book to you.

In the remainder of the book the authors try to give examples what metrics combinations should be used to detect specific structural problems and what refactoring should be used to solve a specific metric result. Those answers are often way to easy. If you're a fan of domain driven design, you are probably trying to base your design on the structure of the domain. So you can't just mechanically apply standard solution patterns to your problem, but you have to find the right kind of design for your problem domain.

Conclusion


For me this book was definitely worth reading. I'll try the tools mentioned in the book and see how the visualization techniques can be applied in real life. Since even the authors admit that metrics are most useful to get a starting point to assess legacy code, I don't think this book helps me a lot in my current work environment where I am still able to overlook the complete project. But the book helps you to view code and code metrics from a new angle, broadening your understanding.

Saturday, December 23, 2006

The Day The Mouse Broke

My wife and I are visiting our families at Christmas. This morning I sat down at my mother-in-law's computer in order to check my daily spam when the mouse broke. OK, it didn't really break in the sense of the word - I just had to explain my mother-in-law that you have to charge rechargeable batteries before using them in your wireless mouse.

So I put the batteries into the recharger and realized that while the batteries were powering up I had no mouse. Since not using the computer for a full day (my god) was no option, I had to figure out how to use Windows with nothing but a keyboard. The principle was not new to me, as I already controlled my Unix flavored operating systems (like emacs) with keyboard FSAs and never really missed anything. But on a Windows XP box this turned out to be a whole new experience.

First I remembered the "Windows Key". I just realize that I don't know what to do if you don't have a Windows and a context key (first one left of the right control key) on your keyboard. Fortunately my keyboard got them. Anyway, the Windows key helped me to get Thunderbird and Firefox up and running. Thunderbird is really nice to control via keyboard. It's intuitive, and while it's not quite as comfortable as using your mouse, the basic task of classifying the spam mails into the spam folder was no problem.

Then I tried to use Firefox. At first this was rather awkward. Since the only keyboard control key I knew was the tab key, I tabbed endlessly through the user interface before I was able to extract the basic key combinations from various sources on the web:


  1. F6: Change frame

  2. Ctrl-L: Address box

  3. Ctrl-K: Search box

  4. Ctrl-W: Close current tab

  5. Ctrl-PageUp/PageDown Previous/Next frame



Equipped with my new knowledge I entered my Wordpress administration page and tried to start a blog entry. Don't try this. It simply doesn't work. I nearly tabbed my brain out of my head. So I needed a Firefox plug-in to save my day.

Searching for "keyboard" on the Firefox plug-in page revealed the NumberFox extension, which I couldn't get to work, and the Hit-A-Hint extension. Hit-A-Hint worked great for me and I was able to do some serious browsing now. After a few minutes I stumbled across Mouseless Browsing. I couldn't find this one at first, because you usually search for "keyboard" and not "mouse" if you actually lack a mouse.

All of the solutions above share the same common principle. For every link, button and edit field on a web page a number is shown. If you enter this number in a special finite automaton mode you can directly browse there without tabbing to death.

For full blown keyboard control Mouseless Browsing is better suited. You can use it from within edit fields and it has a consistent interface for switching between tabs. It even supports to select a link instead of following it, which makes Firefox show the link target in it's status bar. But it feels a log more sluggish than Hit-A-Hint.

Hit-A-Hint is a quick and small solution, but you have to reenable it on every web page and the default configuration features the "h" as start key for your finite automaton, which is quite inconvenient if you want to enter "hello" into a text field.

While searching for firefox extensions that make my mousless life easier, I found the English and German dictionaries to get inline spell checking support in Firefox. I hope my blog entries will gain some quality with regards to spelling...

Hey, I wrote quite a lot today. This shows that with the right combinations of tools it's easy to blog, search the web and use dictionaries all at once without a mouse. Praise the inventor of finite automaton theory!

Wednesday, December 20, 2006

Top 10 Ways To Demotivate Your Programming Team

If you're in charge of an overly motivated programming team that meets all deadlines and produces high quality code you may recognize that they don't really need you. Here are 10 tips how to regain control.

  1. Set up impossible deadlines!
    Repeated failure demotivates even the most undeviating member of your team. If you don't meet deadlines and are not trying to do something about it (like improving your software process) every new deadline will be a farce. You can be sure that in this case your team members will see every time estimation as a torture, randomly guessing some numbers, hoping that this time everything will work out. But of course they'll know that it can't work (you set an impossible deadline, remember), so they will be demotivated enough to get a nice vicious circle started.

  2. Let them work overtime!
    I wrote let them instead of make them intentionally. Often software developers actually like to program. To make sure that they will introduce a lot of errors, which will eventually demotivate them, you just have to let them work. And work. And work. After some hours they will get tired (but will not recognize this state themselves) and will just check in some messed up code. Time works for you on this issue. If they don't work overtimes for fun, just make them (see 2 for a more humane way to achieve this).

  3. Don't allow breaks!
    This is tightly coupled to 9. If your employee works overtime but makes a lot of breaks you gain nothing. The geeky brain has surprisingly quick regeneration capabilities (especially if a lot of caffeine is involved). So you basically have to combine 8 and 9 to get the pack tired enough. This way you maximize the error rate which will eventually yield the demotivation you aimed for.

  4. Place a ban on laughing!
    You can use this tip not only for programming teams. If you want creative workers to produce nothing useful, don't allow them to laugh or even better: don't allow them to talk. When they're quiet and unhappy you can be sure that you will not be able to write code.

  5. Break the coffee machine!
    Programmer (n): An organism that can turn caffeine into code.

  6. Don't shield them from the dirty daily business
    Even the brains of programmers have limited capabilities. So one easy way to demotivate your software developer is to challenge him with tasks he hates. Tasks that have nothing to do with software development work best here. Make the developer lie to the customer about schedules, or make your team hold the customers hand when they don't want to learn the basics to integrate your product into a complex environment. Often you get a nice demotivation by forwarding angry mails from other company's CEOs to your development team or let them handle wobbly feature requests.

  7. Don't challenge them!
    Most developers are motivated when they can work on a real challenge. So don't let them. Of course with software development being a challenge per se, this will inevitably lead to 5. But if you try to implement tip number 5, you have to remember not to give them tasks that challenge too much.

  8. Underpay them!
    While paying more than your programmer is worth will usually not gain any additional productivity, you can easily get a good demotivation by paying less. The important thing is that the developer knows that he's underpayed - this maximizes the negative impact on his overall performance. You can easily drop the productivity by a factor of two or three depending on the basic motivation level of your employee.

  9. Bribe them!
    And do so generously! Promise them a lot of money if they meet some utterly impossible deadlines (see 10). You can be sure that this will motivate your programmer - to mess up. She will work overtimes (see 9), sitting in front of her computer without a break (see 8), not accepting any interruptions by coworkers that want to cheer her up (see 7) or take her to the coffee machine (see 6). She will be concerned about the figures all the time to make sure that everything is all right (see 5).

  10. Infiltrate a team member who is demotivated anyway!
    If you don't want to use 1 to 9 for ethical reasons, you can always find those people who are demotivated anyway. These are mostly people that don't really want to develop software and just do it for the money. Since it's mostly easy to make everything look bad, this is usually what they're really good at. And since they don't want to work, they'll pull everybody around them down into their little black hole of demotivation.

Sunday, December 17, 2006

Review: Domain-Driven Design

When I wrote my first computer program in BASIC I didn't know anything about software design. My variable names used to be mathematically short and contain a lot of numbers. I wrote tightly coupled functions without parameters and synchronized the whole mess by a myriad of unstructured global data.

This is what naturally happens when you grow software over a period of time. Since I didn't have the mathematical background at the age of thirteen, short variable names seem to be a natural choice for human beings. You start with a seed and add functionality on a step-by-step basis, breaking up stuff at arbitrary boundaries.

I did appreciate the advantages of high level languages, though. When the 64k of BASIC data space and the interpreter's performance limited my possibilities with regards to game programming, I started using C as primary language with some inline assembler for the critical parts. At that time I created my first library package for graphical functions and prototyped some game built upon this foundation.

This was my first technical domain abstraction. Splitting up the software in a library component and a domain component came naturally back than. Of course the library design was crappy and the programs were still tightly coupled to the library implementation.

At that time I also tried to learn C++ from the Borland C++ programming reference, but I couldn't grasp the concepts. I probably didn't really try to, thinking that I already knew how to create working software - I had a nice working repository of gimicks at that time.

The next critical step in my understanding of software design was to drop my arrogance.

One of my first software engineering classes at university covered the basics of object oriented software development in C++ using the STL. The first exercise we had to finish was a small program of which I don't even remember what it was all about. A friend of mine and I worked on this exercise together. We both had programming experience and had a lot of fun hacking together a sharp-witted mess of code. The teaching assistant took his time to comment on every single part we messed up, giving us an overall rating of zero points.

This was the day I started to realize that the main challenge in programming is not to get a working program, but to create a maintainable, readable and easy to debug program.

At university I took part in a few programming projects and started an open source project with a fellow student. During those experiences I developed a strong sense of how structured abstraction can simplify software development. Then I started to work as a software developer and architect. When trying to communicate my architecture and design ideas, I realized that there are more aspects to software design than abstraction, low coupling and high cohesion. But, again, I couldn't grasp the concepts.

"Domain-Driven Design" is all about this additional aspect to good software design - the domain language. You can build a piece of software with low coupling and high cohesion and superb technical abstractions in a technical language that restricts software evolution.

Eric Evans proposes a domain languages built upon phrases that describe the implementation of use cases in the software. This is a concept very similiar to test driven development, where you write down how you want to use your objects before implementing them, being able to change the design while writing the test.

But in "Domain-Driven Design" Evans demands a stronger concept: absorb the domain language from the domain experts. Build a coherent language to express concepts and design descisions.

The model couples the software to a pool of associations.

This is a new level of coupling encountered when building software. It is not related to the technical coupling of software modules. This is just what goes on in the brains of developers when confronted with software. The underlying model limits the way we think about software. This is not always bad, as a good model will bind the parts that are irrelevant during development and allows us to concentrate on the important aspects.

A domain driven model increases the probability that modules may be reused in the domain the software is developed for.

While many developers intuitively know what domain driven design is all about, Eric Evans manages to communicate the concepts in a way that makes them explicit, rather than implicitely hidden in the developers train of thought.

The book is not a page-turner, since most of the concepts are not new per se. It lacks the driven spirit of Kent Beck, or the deep insight of Fred Brook's "Mythical Man Month". I can't say if "Domain-Driven Design" can help a student to boost design comprehension - I think it's rather hard to read if you lack the medium level knowledge the concepts in this book are built upon. But I recommend this book to those that already know what software design is all about intuitively and want to be able to put a finger upon the "big picture".

Monday, December 11, 2006

NEPOMUK - Creating The Social Semantic Desktop

Yesterday the KDE Commit-Digest introduced a new project called NEPOMUK which attracted my attention. Ignoring my buzzword alarm I'd call it "Web 2.0 meets the Semantic Desktop". In a first step NEPOMUK implements a framework to store and manage meta data for files. Now the new idea is to bridge the gap between formal ontologies (idea of the semantic web) and oceans of unstructured online data (folksonomies).

There's a lot of research on semi-formal methods going on, which looks very promising. Of course many projects tried to reach exactly the same goal, but I think that NEPOMUK has a real chance.

NEPOMUK starts with a simple integration as meta data framework in KDE. This way it creates value right from the start. Since KDE 4 is going to be available for Windows, the meta data based semantics will be available there, too. It doesn't try to do everything at once like WinFS does. It is just an extension to the current file model we all know.

Desktop search engines like strigi can integrate the new features of NEPOMUK and collaborate in a way that makes data access what WinFS wanted it to be. This way the desktop will be enhanced, not reinvented.

The next step is to integrate the personal knowledge management with the folksonomy based web applications. In my opinion this will be the great challange, since computers have a hard time understanding semi-formal data. But since NEPOMUK is integrated into KDE, many developers will be available to create the semantic online integration step by step.

I'm very excited about this new project and will follow it closely - this could very well be the hour of birth of a new desktop concept: the social semantic desktop.

Sunday, December 10, 2006

Censorship Actionism In Germany

After the recent amok run in Germany you see helplessness everywhere. But of course the important social and political organizations from Christian churches to the regulars' table know the easy solution:

Just censor computer games and everything will be fine.

Of course killer games must be the cause for people to run around and kill. What else. Apart from the original sin humans are born without a spot. And history tells us that it always works to make things illegal that we don't approve of. Gain control by censorship. And the only solution to bad things happening is control. What else. Humans are bad by design, you have to control them.

Oh, wait, you say that computer games may not be the real cause, but merely a symptom - or, even worse, just a coincidence? You really say that most male teenagers play killer games on their computers? No, I just don't believe this. My son most definitely does not. We're good people.

I'd really like to live in the 1940s. There were no killer games. The world must have been a peaceful place back than.

When will people learn that censorship is not a solution? That censorship is a new problem artificially created by goodwilling people? When will people learn that a society must solve it's problems from within?

I can think of a really good reason why people run amok: a cold, anonymous society where the only value is profit, where you're laughed at in public if you're a looser.

Friday, December 1, 2006

The Crazy Class Layout

When I read books about software development there is one thing that increases my blood pressure to clinically hazardous hights: The class layout.

Regardless of whether they're classics or quite modern, whether they use C++, Java or Python, whether the topic is software design or technical wisdom, they follow the same pattern for the layout of an object oriented class definition:

class FunnyExample
{
private:
FunnyDataType funnyData;
FunnyDataType2 moreData;

void somePrivateFunction();

public:
FunnyExample();
~FunnyExample();

theFirstPublicFunction();
};

The private data is at the top.

In all the books I read, I never found anybody explaining the reason for the private-at-the-top layout. In this blog entry I'll explain why I consider this "bad practice".

When the programmer opens a file like this, the first thing that she sees are the data implementation details of the class. When she writes code using this class, she will probably not be able to forget about those implementation details and use them subconsciously, which makes it harder to change those details afterwards.

This class layout contradicts the object oriented design idea: The class specifies an interface, a set of "messages" that can be sent to an object. In my experience this class layout often shows that the programmer didn't understand the object oriented idea. Classes are simply used as convenient data containers and methods are used as ways to manipulate their data.

But most of the time an object oriented class should be a reference to a domain concept. Methods on this class should be ways to interact with a domain object. Data oriented design leads to a technical view of the solution, rather than the problem, which will be hard to maintain later. Writing the public interface of a class at the top stresses the message oriented design.

Organize a class layout from most used to less used from the perspective of a developer using the class.

This implies putting the private data at the end of the class definition, where it is hidden away if a developer just want's to use the class:

class FunnyExample
{
public:
// this is what I see first when I open this source file

FunnyExample();
~FunnyExample();

theFirstPublicFunction();

private:
// if I just want to use the class, I can stop reading here

FunnyDataType funnyData;
FunnyDataType2 moreData;

void somePrivateFunction();
};