In my previous postings I talked about two perceptions: 1. I don´t see any real signs that make our trade of software development singular and hard to compare to other industries. 2. The rate of change in our industry has increased very much in the past 10 to 20 years and makes it impossible to keep up our attitude of allround programmers.

So what do I make of these perceptions?

Conclusion: Software Development needs much more specialization

My conclusion is, software developers need to change to be able to cope with the raging techology tsunami.

The past 20 years we´ve always waited for technologies to become better to solve the software crisis. The next compiler would be faster, the next UI tool would be more intuitive, the next server generation raise us to a new level of abstraction.

But what have we got? More languages, more database access APIs, more servers, more complex IDEs, more non-functional aspects to look after. Has any programmer been fired because of more productive tools? I haven´t heard of any. (If they get fired, then it´s because of some merger/acquisition or customers are not paying anymore etc. It´s because of economic reasons.)

So all the changes in tools so far have not ended the software crisis. There is more software with higher quality than in the past to produce, than todays programmers can deliver.

For me this means, we should start to change another parameter in our system. We went from Client/Server to N-Tier, we went from Waterfall to Agile, we´ve got OOA, patterns, Intellisense. Everything is new and better (and still ever changing) – except for the people.

The people haven´t changed much in the past 20 years. They are still living in this world of “I once learned the trade and now I´m able to solve any problem.” They still see themselves as allrounders. And the process of software production follows this attitude in many projects.

My believe is, there lies a lot of potential for improvement.

And since our trade is not singular, we should look left and right how others have evolved over time.

An obvious trait of everything we buy is, it is the product of a process in which many highly specialized individuals/companies cooperate. Look at your car, TV, cell phone, house, even the next hamburger you eat. They are all the result of a long chain of producers.

A high division of labor and a shallow production depth are common to all production processes behind our everyday things.

And look at the education market: There are dozens of professions you can learn to be involved with the product “car”. Or have you ever sat through the credits of a major movie? Did you count the number of different jobs/professions taking part in its production? There are hundreds of people involved and all are highly trained (or at least experienced) professionals. (Otherwise they would not be on the payroll of a major Hollywood production.)

Now think about an average software project. How many professions do you see at work there? Is it 2, 3, or 5? Let´s see… I count “programmer”, and … Well, I´m not talking about role, I´m talking about professions, i.e. a trade you can actually learn, where there exists a curriculum, a common agreement on what you should now as an xyz expert.

Even though on an average (!) software project you will probably find at least “project leader”, “architect”, “programmer”, “tester”, “deployer”, “documenter” as roles – they are most often staffed with people who just learned the trade of a software developer. A typical project leader is just a very senior programmer, the same goes for an architect. A tester sometimes is a programmer who´s turn it is to test. Working on deployment sometimes is viewed as punishment. And let´s not talk about documentation…

Most of those roles are filled by people who may be switched to other roles at any time. So it´s perfectly understandable, that they entertain an allrounder-attitude.

Back in the good old times, when programmers truly were artists, deployment was just copying a couple of files, documentation was for whimps, testing was not needed (or was done by the customer), and architecture was emergent. Well, at least we all remember it to have been like that, don´t we? :-)

However nowadays, all of these roles require very different skills. There are many tools for testers, deployment is not easy at all (despite XCOPY deployment and ClickOnce for the .NET Framework), and architects probably have the most difficult job of them all. (They need to be the true generalists with a very good knowledge of a lot of technological options, plus they need people skills.)

In addition to the many tools and material options (see the box “What I mean by tools and materials” in posting #2 of this series) for those roles, there is a vast number of challenges for th unsuspicious programmer role. The term programmer does not distinguish between a guy working on a GUI or on domain logic or database access or security or internationalization or application distribution etc.

Microsoft now has started to provide tools in different flavors for different roles (see the box on the right of the Visual Studio Team Systems homepage; it lists architects, developers, testers, and project managers), but nobody seems to see a need for defining more subroles within the programmer role. This smells of underspecification.

Since long programmers used to specialize in a vertical industry. A game developer rarely will switch to embedded systems for industrial plant automation; a compiler specialist does not want to become a guy on a business software team; a domain expert in the insurance industry working on enterprise applications will not switch to the telecommunication industry.

But a horizontal specialization is comparatively rare among programmers.

To be successful in the future, though, I think it is inevitable.

I don´t know exactly where the boundaries will lie between specialized areas of expertise, but a rough sketch would probably separate architecture/design, frontend, domain logic, data access, security, deployment, and testing from oneanother. (Maybe it´s worthwhile to specialize even more and separate Smart Client frontends from WebForms from mobile form factors.)

Where the knowledge horizon lies, will also be determined by how many tools/materials an area like frontend or data access contains. At least to be equally knowledgeable in WinForms/GDI+/WebForms etc. and ADO.NET/SQLXML/T-SQL etc. I think is impossible.

But why specialize? Because only by specialization quality of products can be attained.

The quality of a software product is determined not by delivering a functional complete program. Fulfilling functional requirements is the premise. We don´t need to talk about that, don´t we?

Rather software quality is determined by non-functional aspects like performance, scaleability, flexibility, correctness, robustness, maintainability, speed of development etc.

Of course, almost any programmer can bang out some code that somehow fulfills the functional requirements of a project. But did he use the technologies to their best? Did he even choose the most adequate technologies available?

As I understand software development, one must have considerable experience with a technology to put it to good use in a mission critical project. Also, to select between several technologies one needs to have experience with all of them, lest the decision is uninformed.

Now, to gain experience or even considerable experience it takes time. However, the time in a programmer´s professonal life is pretty much constant.

What happens, when the number of technologies relevant for a programmer increases? The time he can devote to each to gain (considerable) experience diminishes. That´s a very simple and obvious calculation. This becomes worse, if the complexity of the technologies also rises. And it becomes even worse, if the number of non-functional aspects to heed increases too.

I doubt the nowadays common allround programmer can cope with this situation and wholeheartedly claim, he can still produce high quality software. If this is possible, I´m a whimp and should think about switching to some other profession.

This conclusion might make feel many uneasy. I can understand that. Whenever a deep believe is shattered or a habit needs to be changed, (emotional) resistance springs up. But feeling the status-quo should not change is not really a proof for anything.

I emphasize with the many allround programmers and small shops who think, they depend on them being allrounders. But I nevertheless can´t imagine how they will be able to claim before their customers, they know it all and have chosen the best tools/materials while at the same time keep up with all the different non-functional requirements (the customer not even thought about, but nevertheless expects to be considered).

To go even further, I need to say, specialization will entail many other changes. A very obvious one I´ll mention right away: Once programmers start to specialize there will be not enough work for everyone on every project. A small shop with three allround developers not continuously will have enough work for maybe a security specialist or a deployment expert. A large software department in a bank on the other hand will be able to keep the guy who specializes on Web frontends, because there´s always some project going on, which needs his expertise.

So what I see as an inevitable implication of a trend/need towards specialization is an increase in outsourcing. Get an expert on your project when you need him! This there will be a larger market for freelance programmers in the future. But of course, specialists are free to flock together and found a company that in itself specializes on something. Their foci can be homogenious or heterogenious; both could make sense. What will not make sense, though, is to succumb to the feeling, you´d be better off as an allrounder.

Instead of keeping broad knowledge, start to focus.

Instead of being a loner, start to network.

Allround skills in the future of software development will manifest itself not in individuals anymore, but in teams.

When something starts to overwhelm you, the natural reaction is to focus. When you first drive a car, a tunnel view is dangerous. When you need to cope with an ever changing and broadening environment of technologies, a tunnel view is the basis for your survival.

Think of it: We are programmers and not gatherers anymore. We are already highly specialized. Why stop at the current level?

So far, the customers of software products have not (often) asked, how software is produced and who produces the software. But that will change! The demand for higher quality software will drive to the software manufacturers to lay open, how (!) they are ensuring quality. And I don´t think any customer will be satisfied with an answer like “Hey, we´re all allrounders here at Xyz Software Inc. Any developer can jump in for the other any time. We don´t believe in specialists.” But that´s the situation today in many, many software developing departments/shops.

But would you, when buying your next car, go for the car manufacturer who´d answer you in that way? “Hey, our engineers are not specialized! We are proud our motor engineer can jump in for a car body engineer any time!”

Cathedrals were build by a large number of different professions. Aircrafts are build by a large number of professions. So are TV sets. Just software should be singular in that a single profession – software developer – builds the actual product? That cannot be true.

But of course, specialization leads to even more implications. Once developers start to focus their skills, a lot of thinks need to change. Some of those implications will be the topic of future installments of this series.

[See here for an overview of all postings of the series on the future of software development.]

Ok, so now that any “attitude” is out of our way (see my previous posting for details), we can start to look at what is the real challenge for programmers today.

Perception 2: Software Development is changing at a much higher rate than 20 years ago

What makes a trade, an industry? It´s of course the products which it produces. Bakers produce bread, waiters produce a “dining experience”, directors produce movies, programmers produce software.

But to produce a quality product, skills, knowledge, tools, materials need to be of high quality. (Let´s leave methods and processes aside for the moment.) A master of his trade needs to have the rights tools and materials, be able to use them on a high level (skill), and be aquaintant with their capabilities/limitations (knowledge). Sounds like common sense, right? I´d say so.

Now, does our trade lack quality tools? No, I´d say, there are a lot of quality tools. A whole lot.

Or does it lack quality materials? No, there a lot of quality materials. A whole lot.

But what about skills and knowledge? Does our trade lack quality in this regard? Yes, I think so! And I think this is an inevitable outcome given how we view our trade. So I don´t really blame todays software developers – but if they don´t see the writing on the wall and don´t change, there will be no happy end for many of them.

We are like a frog sitting in a pot of water. If you heat up the water slowly, the frog won´t realize it and gets boiled alive. (But if you put a frog into hot water, it jumps out immediately.)

Like the frog we are in a system that was good to live in 20 years ago. But since then it has changed – but so slowly we are not conscious of that change. Maybe we just feel some diffuse pain and can´t lay our finger on it.

So what is the change in our system? Where´s the heat? The heat is in the faster and faster movement of our tools and materials. And in addition to that, the products we are requested to manufacture become more and more complex – with the tools lagging behind in their abstraction of this complexity.

20 years ago a master programmer´s toolchest just contained a couple of tools: a formal language or two, a very simple IDE (or just a text editor like vi), a debugger, … what else? Ok, on Unix systems there were those lovely command line tools like sed, awk etc. Great! But still a pretty small number all in all. Also, there was a strong agreement on what was the “canon” of tools you should now. This was fine, because programming was still an “art” and programmers where the universal heroes for solving any software problem.

What about the materials 20 years ago? Hm… there was the C library. You needed some API for character based UI, a data access API (what was your favorite ISAM library?), maybe some printing API? What else?

Or your world was even smaller: you just used Cobol or a 4GL like Zim or Amber.

Let´s face it, your choice of tools and materials was pretty small.

However today, there is no limit to the number of tools available. Even the number of tool categories is expanding all the time! 10 years ago there were no Application Servers. 5 years ago there were no Business Process Management Servers. So how do you keep up with the acronym (and code name) avalanche coming down upon you? What´s LCE? What´s QC? What´s STA? What´s MOM? What´s SOA? (I know, that´s an easy one ;-) What´s SOAP? What´s XQuery? What´s BEPL? What´s VSTO? What´s ORM? What´s MARS? What´s XAML? What´s GPL? What´s IRS? (Upps, wrong trade ;-)

Ok, I guess you got it. And I even left out the non-acronym technologies and code names. And I left out the many “instanciations” of concepts/technologies. There is not one data grid control, but many. There is not one installer tool, but many. All with subtle (or not so subtle) differences. And ever changing. A next release is always upcoming.

The rate of change and well as the breath of changes as well as the complexity of technologies has increased so much in the past 20 years (and especially in the past 10 years), that we cannot possibly think, we can cope with it without changing ourselves.

To make it even clearer: We still work around 40-60 hours a week like 20 years ago. And this is not gonna change much in the future ;-) But within the same amount of time, we now need to keep track of maybe 5 to 10 times as many tools and materials plus the increased complexity of the technologies and our products.

Is that possible if it was a specialist´s, a hero´s job 10 or 20 years ago? No!

Now, you might argue, the tools are so much more productive nowadays. To do a Windows UI with C took a long time, to do it with VB1 was a snap. Sure, of course some tasks have become easier through improved tools. Garbage collection is a godsend! And ServicedComponents are much easier to host in COM+ than ATL/VB6 COM-Objects. But my feeling is, the productivity advancements do not compensate for the overall rate of change. They just mitigate it a bit. Or new developments even add to it: Earlier I had a crude printing API to use for all my printing tasks. Today I can choose between several reporting engines, XSLT-FO, and PDF.

To come back to quality products as the goal of a trade: I think, we are at a turning point in our industry. Given our in general unchanged attitude of 20 years ago (“Once a programmer you can produce any piece of software!”) we will be less and less able to produce good quality. Because what quality needs is not just quality tools – which we certainly have (see list above) -, but skill and knowledge.

Skill and knowledge require time. Time to acquire knowledge, how tools work, what the capabilities and constraints of materials are, and time to hone your skills by actually using tools and materials.

Unless you actually build up experience in using tools/materials, you cannot wield/process them like a master, and you cannot even choose the best tool/material for a given task. Just reading an article or two about LCE does not (!) make you a master. Just seeing a presentation of Notification Services does not make you a master. But only a master can decide for a project, which technology to use, which not to use, and how to use the chosen one.

How should a host of “general purpose developers” (GPD ;-) using mainly general purpose programming languages (GPL) be able to master that many more tools/materials to produce even higher quality software? (I hope we agree, that software quality in general is not really good – at least not for version 1.)

The answer: Not – at – all! It is impossible!

So what should we do? Well, that´s the topic of my next installment.

Let me start my reasoning about how the people-side of the future of software development might look like with two perceptions that form the basis of my argumentation.

Perception 1: Software Development is not that special

I guess we all know those storys of exceptional programmers living on just jolt coke and pizza while developing single handedly a new operating system :-) And we all now the proverbial “diva status” some programmers claim. And we all know how “ordinary people” (our customers) complain about the often introverted natures of programmers and their underdeveloped communication skills.

Well, as always there is some truth to such kind of storys. And we can speculate where the reasons lie, what maybe makes dealing with computers so attractive for introverted personalities. But I think much more important is to recognize the underlying attitude of our trade that´s still nurturing these kind of perceptions: Software developers still really think they are something quite special.

Remember Donald Knuth´s “The Art of Programming”? Although this book probably sits more on the shelf than it is studied, its title summarizes how generations of programmers view themselves: as artists. In their view software development is an art, a craft, something that is close to composing music. In the center of this picture is the programmer (possibly sitting alone in his cubicle) sculpting an ingenious algorithm out of the clay of the formal language of his choice.

Well, a nice picture and I sometime indulge in feeling like that when pondering the intricacies of parallel programming or the like. But it´s not reality! Maybe it has been like that 20 years ago, but we cannot hold up such an attitude any longer.

20 years ago a programmer or software developer or software engineer had been a highly trained professional in a narrow field of expertise: software development. This distinguished him from carpenters and aircraft engineers.

On the other hand, once highly trained in this trade, the programmer felt ready to tackle any and all problems. Regardless if he was asked to develop a compiler, a book keeping application or painting tool he never would have declined such a request. He felt competent to wield the state-of-the-art tools and materials to produce a satisfying result. He just needed complete requirements and enough time to wreck his brain – which was his most important tool.

Back than this might have been a valid attitude, but it got carried over to the present. And that´s plain wrong and makes it very difficult for developers today to produce high quality and get job satisfaction.

20 years ago software development was special in that it had few tools and materials and mostly relied on the creativity of single developers with deep knowledge in theoretical concepts (like “algorithms and data structures”).

Also software seemed and still seems to be so different from anything else humans produce. This adds to the trade´s attitude of being special and unique. Software is so abstract, so highly formal/structured, so ephemeral. Software developers were the digital guys in an analog world. Bits and Bytes made ordinary people gape in awe. Programmers were the heros able to tame the computer beast by wielding their formal language whip. Wow!

But, hey, let´s get real! Our world of 2005 is digital. Music is digital since we switched to CDs in the mid 1980s. Video has become digital. Telephoning is the last bastion about to fall when finally VoIP is taking off on the consumer market.

Computers in some form are everywhere and RFID will add to the pervasiveness. And kids get aquaintant with programming in elementary school. Software development has lost its nimbus of a secret art.

But how about our products? They are digital and can easily be mass produced. (Just copy that file.) And they are highly individual. And they are made on and for changing requirements and a long maintenance life. Isn´t that quite unique?

Well, I wouldn´t say so. Although analogies are a difficult thing and usually don´t explain everything, let me try some:

Are there no other products that need long maintenance? Sure, there are. Chemical plants, aircrafts, and even cars are build in a relevatively short time and need to be maintained over a very long time (up to decades). Or even take a city as example: You don´t build a city and then leave it to itself. Rather it is constantly changing, buildings are torn down, new ones are build, subway tunnels are dug etc. Some structures are more volatile than others. But over the decades or even the centuries a city changes massively without losing its basic character and while always fulfilling its main purpose: offer an infrastructure for the inhabitants. My conclusion: Mankind or engineering in general has a lot experience with long lasting structures that need to undergo quite some changes during their lifetime. Software is not special in that regard.

Are there no other products that are mass produced but always unique? Sure, there are. Take roller shutters for example. Each roller shutter usually is tailored to the exact measures of a window/opening of a house. Or – an analogy I even like more – take a movie as an example. Each movie is a unique product. Hollywood produces 400 movies each year, the Indian Bollywood even 800 each year. And despite its uniqueness (and often changing requirements; think of producers as divas ;-) it is an industrial product and a result of a coordinated effort of hundreds of individuals.

So I´d say, long lifetime with high maintenance and uniqueness are not really attributes of software development, which justify a special status or attitude. Also the easyness of multiplication is not unique. The music and video industry are facing the same problem. And print is struggling with is since the invention of photo copying machines.

But what about the ever changing requirements? The waterfall model failed for software development, but it works for civil engineering. Yes, the requirements seem to change much more often during the manufacturing of software compared for example to a movie. But does that make software development uncomparable to other manufacturing processes? I don´t think so. Because not the magnitude of volatility of requirements is crucial for a comparison, but whether the tools, materials, models, processes, education etc. match a given volatilty.

And therein lies the crux, I´d say! Don´t try to compare apples with pairs. Don´t try to compare a mature trade like “building skyscrapers” or “manufacturing cars” with a comparatively young (or immature trade). So, you should not take a rediculous comparison for a prove of uniqueness.

When comparing software development to some other industry/trade, first ask, if software development can match the other side´s maturity and in how far that could affect the outcome of the comparison. My opinion: Software development is still after some 50 years pretty immature – but not as unique as most people think. (The uniqueness of software development, though, might lie in its stubborn self assurance of its uniqueness. Remindes me a bit of autism.)

But, now, finally, what about the lack of natural laws in software development? Yes, that´s true. That poses a certain difficulty and accounts for some uniqueness. When planning a building or a CPU, the effects/stability of certain designs can be assessed by using mathematical formulas or by simulation based on natural laws (i.e. again mathematics). Before even digging the smallest hole you know if a bridge will be able to carry the trains and cars rolling over it later. That´s because you know the exact parameters of the ground it is build on, the stones, the steel, the concrete etc. which are going to be used in building it. For software, though, you cannot just compute its stability or correctness or quality. Contrary to most other trades you need to constantly monitor and actively asses it (that´s called “testing”) or model scenarios when in doubt (that´s called “prototyping”). And since each software is unique, you are never done with testing.

But does this uniqueness justify the software development´s trade attitude of “Oh, boy, are we special!”? No, I doubt it. It is not so important how we determine correctness of our products. It is important to have a mature methodology for doing so that is adequate for our tools and materials. And likewise it is not so important, that software development differs so much and lacks “mathematical precision”. We must not feel inferior because of that. We just do it differently. Correctness is determined in different ways when building skyscrapers, finding a cure for a disease, coming to a judgement in a trial. So why can´t we be different – and still be comparable to other trades?

So when comparing software development to other trades the question is not, whether we produce similar products. Rather we should ask, do the processes differ fundamentally? We should look at mature and established industry and see what they consist of: there are tools, materials, process phases (e.g. planning, manufacturing, maintenance), division of labor, quality assurance, professions, education etc.

Then we should compare our findings with what we have in software development. And we can only realize: all of this is present in our trade. So software development does not fundamentally differ from other industries!

But if we don´t differ fundamentally, why do we have a hard time liking software development to other trades? Because the level of maturity of our tools, materials, process phases, division of labor, quality assurance, professions, education is so different from their´s. And the level of maturity does not even always match the complexity of the problems to solve.

Don´t get me wrong, there are good tools at our hands and there are excellent programmers. But still we can and should learn a lot from other much more mature industries. UML is an approach to learn documentation and visual modelling from civil engineering or electrical engineering or processor design. Software Factories now is an approach to learn from mass manufacturers about tool specialization and manufacturing. Now my question is: What can we learn from other industries in terms of process organization, education, quality assurance, divison of labor?

And if our trade is not unique, neither is our profession as software developers. We should not deem ourselves as artists or divas or very special in general. We are ordinary hard working people in a demanding business with some very specific challenges. Not more, not less.

The only thing that maybe makes us special is, we need to deal with a lot more change than other professions. But that will be the topic of the next installment of this series.

On the Future of Software Development #1

Motivated by I a conversation with Steve Cook, one of the fathers of the Software Factory concept ([1], [2]), I´d like to share some thoughts with you about the future of software development. However, contrary to what you might be thinking now, I don´t want to speculate much about the next versions of the .NET Framework or how virtual shared memory could help to solve interop problems or the benefits of Intentional Programming.

No, sorry, I´m concerned with people and processes and organization.

So what is it that´s driving me to take up a non-technical subject? It´s an uneasyness that befalls me from time to time. For example when I look at the MSDN Online RSS feed.

Each week it swamps me with so many headlines of interesting topics. And I realize how I get tense when I try to figure out, when to read all this stuff.

Of course I know, I don´t "have" to read it all. It´s just offerings. But still... somehow it doesn´t feel good to ignore much of this content.

However this is just the initial trigger of my thinking. I can deal with the "information deluge" and don´t feel bad, if I don´t read up on the latest ASP.NET 2.0 development, am not much interested in the latest Indigo CTP, and am ignorant about the benefits of VSTO.

This position, though, is the result of some pains I went through. Because, what I painfully realized is, I have to say good-bye to a picture I had of how software development should work today, or, hm, of how I can stay competent as a software developer.

My personal conviction now is: To overcome the proverbial software crisis we need more than an improved VS.NET or the next version of the .NET Framework or even Software Factories. However, I have to admit, I deem Software Factories very important. It was the term “factory” that made me think and become or concious about the current situation of software developers.

To put it blandly: I think, instead of asking for evermore better versions of our tools, we also need to ask ourselves, in how far we could help software development by changing our attitude towards  our profession.

Whereever a problem persists for a long time – and I think the software crisis is a very persistent problem – and seems to be immune to the efforts invested into its solution, I think it very prudent to step back and see, if maybe the approach is wrong or lacking something essential.

So, when I stepped back, I found, most software development is stuck in 1980-thinking. Don´t get me wrong, our tools are much more advanced today! OOP is good – although not enough. The .NET Framework is a godsend. And I like application servers and the Internet. So do almost all developers.

What I mean is: Software development has gone through so many changes in the past 20 years – but the software developers have not! They are lagging behind in how they see themselves as professionals, how they learn their trade, organize their projects, and try to keep abreast with the latest developments.

This is a hindrance to breakthroughs in productivity, software quality, and als job satisfaction. And in a couple of postings I want to explain why I think this is so and give some pointers as to how we could change it. Of course I can´t provide a silver bullet, but I would like to instill a and contribute to a discussion that is mysteriously missing from the hype around Software Factories.

If you like, stay tuned… Next time I´m gonna explain why I think software developers need to specialize their skills (more).

[See here for an overview of all postings of the series on the future of software development.]

Links

[1] Software Factories, http://www.softwarefactories.com/

[2] Microsoft's Story on Software Factories, http://msdn.microsoft.com/architecture/overview/softwarefactories/

Are you looking for information on how it feels like, when you use an O/R Mapping tool in your .NET applications in general? How - if at all? - does the programming model change? What is it like to live without DataAdapters and DataSets?

Or are you interested in information on Versant Open Access .NET (VOA.NET) in particular? Maybe you´ve heard about this tool and looked for samples and literature on the Web - but were unable to find anything going beyond the basics?

If you belong to either group this series of blog entries is for you! I intend to do postings on how to program with VOA.NET as I go along and explore the tool myself.

Check out the first installment of the series... It even sports a short video!

You will learn,
-why I´m talking about VOA,
-how to set VOA up on your system,
-how to write your first "Hello, World" VOA program with a persistent class.

Enjoy! And send me your feedback, if you like.

Halbzeit! Mit meinem Vortrag vor der .NET User Group in München am gestrigen Abend habe ich die Hälfte meiner Vorträge gehalten.

Es hat wieder viel Spaß gemacht, der Kontakt mit der Community ist immer wieder angenehm und wichtig. Ich kann also nur empfehlen: Wer noch in keiner .NET User Group mitglied ist, suche sich die in seiner Nähe gelegene. Der Austausch mit Gleichgesinnten jenseits der eigenen Firma inspiriert und macht es auch mal leichter, mit dem eigenen Technologiefrust zu leben ;-)

Und: Das Publikum hat knifflige Fragen gestellt, die ich nicht alle selbst beantworten konnte. Ich habe mit deshalb mit Versant, dem Hersteller des O/R Mappers, den ich als Beispiel für die Technologie vorstelle, in Verbindung gesetzt und werde deren Antworten hier posten.

Heute geht es nun weiter nach Stuttgart für die zweite Hälfte der Tour. Hier die verbleibenden Termine und Ansprechpartner für Details:

10.3. .NET UG Stuttgart, http://www.devgroup-stuttgart.de
6.4. .NET UG Hamburg, Ansprechpartner Jan Waitz, jwaiz@icomedv.de
7.4. .NET UG Berlin, Ansprechpartner Robert Rehberg, Robert.Rehberg@cdmega.de
13.4. .NET UG Bremen, Ansprechpartner Kai Rübke, ruebke@in-spirion.com

Wer noch Lust hat, darüber zu hören, wie man mit O/R Mapping in .NET Anwendungen grundsätzlich arbeiten kann, der kann einfach bei einem der Termine vorbeischauen. Eine Mitgliedschaft bei den .NET UGs ist nicht nötig. Jede Interessent ist willkommen.

See you there... :-)