Simple little things. Placing dynamic images in databound controls

Sometimes there’s these really little things that hardly seem worth the effect blogging about. But when you start googling for the apparent solution, there’s a million-and-one blogs, forum questions that at the least are contradicting.

In this particular case I wanted to set different images in different rows in a Repeater or GridView depending on some property of the domain object I’m binding to. This seems to be pretty straigtforward. And it is. However it’s all these little details that still take up some much time googling, trying them out, debugging that makes it nasty enough.

So a live example. I have a class called ValidationResult. This class has a number of properties, such as Name, Description, but also a Severity. The type of Severity is the following enum.

public enum ValidationResultSeverity
    Success = 0,
    Informational = 1,
    Warning = 2,
    Error = 3

Nothing fancy here.

Now I’ve created small iconic images that match the names of the elments in the enum. So there’s an image informational.gif, warning.gif, etc. You get the picture. The images resides in a sub-directory called Images in my web project.


Next I’ve defined a user control with a Repeater control on it. In code this Repeater is databound to a List<ValidationResult>, using the following code.

List<ValidationResult> views = FormatMessages(validationResults);
repException.DataSource = views;

This straightforward code causes the individual items (rows) in the Repeater to bind to the properties of one of the ValidationResult items in the list.

The Repeater is defined as follows. Most noteworthy is the construct I’ve used to bind the images of course. After googling and puzzling a bit I came up with the following simple solution.

<asp:Repeater ID="repException" runat="server">
         <td valign="middle">
              <asp:Image ID="imbIcon" runat="server" Width="11" ImageUrl='<%# "~/images/" + DataBinder.Eval(Container.DataItem, "Severity") + ".gif" %>'></asp:Image>
          <td valign="middle">
              <asp:Label runat="server"><%#DataBinder.Eval(Container.DataItem, "Message") %></asp:Label>

Nothing too difficult use of DataBinder.Eval() constructions. I’m not very fond of Eval(), simply because of it’s use of strings, which make binding very type unsafe, but it this case I stuck to it.

But note the most interesting code fragmet in here.

ImageUrl='<%# "~/images/" + DataBinder.Eval(Container.DataItem, "Severity") + ".gif" %>'

This very little fragment took me about 20 minutes to get it right. Why? Well, first you will try to use the literals "~/images/" and ".gif" outside of the Eval() expression, just because it seems more logical. Doesn’t work – at least not how I like it. Compiling renders invalid tag errors. Next you find all kinds of blogs that put these literals inside of the expression. Still no result. You will have to be really careful here. And only then I thought of putting the whole expression between single quotes instead of double quotes, which you would do normally. And then it works, as you can see below.


Sander’s talk at TechEd US 2010. How frameworks can kill your projects and patterns to prevent getting killed

Last week, the Microsoft TechEd North America 2010 took place in the great city of New Orleans. I was lucky to be invited to do a talk on how frameworks can kill your projects.

When it comes to Microsoft .NET-connected development, more and more frameworks enter the market. Both from Microsoft and from open source. Think of ASP.NET MVC, Castle, Windows Workflow Foundation (WF), Entity Framework, Unity, Linq2SQL, ADO.NET Data Services, Windows Communication Foundation (WCF), nHibernate, Spring.NET, CSLA, NUnit, Enterprise Library or ADF.

Trouble begins

Once a project chooses to apply one or more frameworks, trouble begins. What if you require features that aren’t implemented in the framework? What if you decide that another framework would have been better and want to switch halfway through your project? What if the author of your favorite open source framework suddenly stops developing? What if the framework contains bugs or omissions? And, what if a new version of the framework is released that is implemented differently? These and many more everyday problems will cause your project to come to a halt, or at least make you perform serious refactoring.

Get Microsoft Silverlight  

Demos and (bad) code

During this highly interactive talk, Sander Hoogendoorn, chief architect of Capgemini’s agile Accelerated Delivery Platform, and member of Microsoft’s Partner Advisory Council .NET, demonstrates pragmatic architectures and patterns that will help your projects to stay away from framework issues, and how to keep code independent of framework choices. Sander presents models of layered architectures, and applying bridge patterns, managers-providers, dependency injection, descriptors, and layer super-types.

Of course, Sander illustrates these insightful patterns with lots of demos and (bad) code examples using blocks from Microsoft’s Enterprise Library, NHibernate, Log4Net, and the Entity Framework. Learn how to improve the structure and quality of your software architecture and code, and how to avoid the pitfalls of applying frameworks to .NET software development.

Alzheimer Architecture

Let’s suppose for a moment that it’ is 1986. And let’s suppose you are starting a new company. A company that sells products or services to customers, as most companies do. Let’s say you selling (surf) board wear. You start selling your first t-shirts and you decide that you need to automate stuff. So you create a list of your customers in Excel, and type orders and bills in Word.

Someone’s father-in-law

After a while business is picking up, more orders are coming in, more boards, t-shirts and shorts are sold, and customers are even returning to your shop. This is where things are starting to get a bit nasty. You are starting to see the need for real automation. So you start asking your friends, until eventually you find someone who has some knowledge of Microsoft Access, mainly because he is using it to print address labels for his christmas cards.

A short while later your new developer, in most cases some friend’s father-in-law, a former accountant, has built you a simple application to maintain customers, orders and delivery statusses. It’s now 1990.

At a regular basis your thinking of new stuff to sell, and worse, of new ways of selling stuff, perhaps even through the internet. This poses new features to your Visual Basic for Applications written back office application. Hence the application grows and grows. Because software architecture is light in Microsoft Access, and software architecture knowledge is not apparently present in your developer’s skills, the code grows in all directions.


Now we’re back in 2010. Because business is still going strong, your 1986 back office application is still there, although it has grown from a simple three-table-and-a-screen maintenance thingy to a code base of over a million lines of code that interacts with external parties for billing, the cash registers in your shops, and also does your enterprise resource planning, including stock and shipments.


And although your friend’s father-in-law still oversees all of the code, implementing the new features you need for your evolved business is getting harder and harder. “Hey, we need to be able to deliver goods in Belgium and Germany too,” you claim. The developer sighs. “Phoe, that is a major change to the system. It’ll take me about three weeks.” With every bug, change or new feature you hope to introduce, the productivity of your developer lowers. Moreover it is due to these changes and new features that always need to be introduced fast, that the software architecture of the system has never been upgraded to facilitate some layering, introduction of patterns, or even migrated to a more serious development platform. There’s just never the time to do it.

Turning 75

To cut a long story short, these days that is not even your biggest issue. The biggest problem is that the only person capable of maintaining the code is still your friend’s father-in-law, who grey haired, these days, is seriously thinking of retiring. Or even worse.

Alzheimer Architecture 

Recently I visited a customer who needs to rebuild her current back office application – and yes, it is written in Visual Basic for Applications. And she needed to rebuild the application really fast. Why? Well, the single developer of the system who had uphold the code for almost two decades is not only thinking of retirement, but actually did retire ten years ago. He had recently turned 75, and was now moving into a home for the elderly.

No cure

Unfortunately, there’s no easy way out of this rat hole:

  • Automated migration will not do the trick, as there’s so many lumps and bumps in the software, that automated tooling will never identify all the finesses in the code.
  • Introducing a packaged applications, such as Micrsoft CRM,, or even SAP or Oracle, is not only expensive, but how do you capture all exceptions and loop holes you’ve introduced to satisfy your customers in such a package?
  • Offshore development is hard too because your whole company, which likely has grown from a happy few to over a hundred employees, is depending on the system. How do your guarantee quality? And who do your trust?
  • Rebuild the system yourself in .NET or Java is also not a very plausible option. There’s no expertise in the company, and moreover, you will need the domain knowledge of your employees who are always very busy with their regular work.

This is when you realize your suffering from the Alzheimer Architecture anti-pattern. It’s a progressive anti-pattern. With each business discission you take, the problems grow, and there’s just never time nor budget to solve it properly. It is as it goes with Alzheimer’s disease. Unfortunately there is no cure.

Spring 2010 speaking engagements

Again doing a lot of talks this spring on a wide range of subjects, from new technology, via enterprise agile to model driven development, but also about smart use cases, domain driven design, UML, and software architectures, design patterns, frameworks and .NET.

This season’s highlights? Not a difficult choice: doing talks both at Microsoft DevDays and TechEd North America is great. But revisiting SET in Zurich is not bad either. And what about the Dutch Testing Conference?


Check out my spring talks below (with links and logo’s):

  • Around the world in 80 slides.
    February 9. Keynote at Capgemini TechEd, Utrecht.
  • Pragmatic modeling using UML and beyond
    March 3-4. Two-day workshop at IT Works, Antwerp, Belgium.
  • We’re not in Kansas anymore. New trends in Microsoft technology
    March 8. Capgemini Micrsoft Practice Meeting. Utrecht.
  • Pragmatic modeling using UML and beyond
    March 10-11. Two-day workshop at Array Seminars, Hilversum.
  • CIO challenges. From enterprise agile to model driven development.
    March 16. Talk Capgemini customer event, Utrecht.
  • How smart use cases will change your life
    March 23. Guest lecture at Hogeschool Utrecht, Utrecht. .
  • Agile development in everyday practice
    March 24. Seminar at Array Seminars,  Nieuwegein.
  • Do’s and don’ts in implementing extension methods
    March 30-31. Talk at Microsoft DevDays 2010. Den Haag 
  • Beyond agile testing
    April 7. Talk at Capgemini Testing Community Event, Utrecht.
  • Beyond agile testing
    Arpil 21. Talk at Dutch Testing Conference 2010, Nieuwegein.
  • Mission impossible? How to survice agile SAP SOA projects
    May 18-20. Talk at SET 2010. Zurich, Switzerland.
  • Estimating with smart use cases
    May 26. Seminar at Array Seminars, Nieuwegein.
  • Software architectures and patterns in .NET.
    June 2. Seminar at Array Seminars, Hilversum.
  • How frameworks can kill your project and how to avoid getting killed
    June 7-11. Talk at TechEd US 2010, New Orleans, USA.
  • Pragmatic modeling using UML and beyond
    June 23-24. Two-day workshop at IT Works, Antwerp, Belgium

October 19. Talk. “Do’s and don’t in implementing and applying extension methods”

SDC Conference, Papendal, Arnhem (

Next week the annual SDC conference will take place at Papendal, Arnhem. As usual the organising SDN community has put together a long list of international appraised speakers, and challenging subjects on the matter of software development and software architecture.


A bit to my surprise, this year I was invited to do 3 talks, with very different subjects: Silverlight and code generation, smart use cases in service oriented projects, and .NET extension methods, which is a very small subject compared to the other two, but still a nice way of getting to talk about OCP, LSP and the new construct. Following the article I wrote for .NET Magazine recently. Should be interesting.

Extension methods

The SDC website refers to my extension methods talk as follows:

To implement the operators that make up the language feature LINQ Microsoft’s .NET Framework designers had to extend existing types with new features. To be able to do this without touching the existing classes, they introduced another language feature in .NET 3.5 – extension methods.

During this talk Sander Hoogendoorn will demonstrate the use of extension methods with simple examples, but he will also investigate the way these extension methods are handled. For instance, do extension methods break the Open Closed Principle (OCP)? What is the open closed principle anyway? Can I use extension methods to break into existing classes, either in our own framework or in someone else’s frameworks (Microsoft or open source)? What is allowed in extension methods, and how do they work?

Read more: Sander at SDC 2009.

Writing better software faster

Published in my Interesting Things column in SDN Magazine, November 2009.

Looking back on twenty years of software development, I must have spent most of that time trying to improve the quality and productivity of software development.

Ever since I started to write small applications in Turbo Pascal in 1988 I got infected with the writing-better-software-faster virus. Right after I finished the second of fourteen of these applications, I wrote my first framework. It took some effort, but writing the following twelve applications took me less time than building the first two.

Darkening perspectives

There are good reasons for increasing productivity and quality. First of all, we have to increase productivity by a hundred-fold to meet up with current demands, says Gartner. Furthermore, technology is becoming increasingly complex. Ten years ago I was working in both Microsoft and Java projects. Anno 2009, I’ve let go of the idea that I even have an overview of either one of them. It is hard enough working with a small subset of frameworks. A Silverlight designer is not likely knowledgeable in NHibernate. Being a Spring guru does not guarantee foxy JavaFX user interfaces.

Despite this darkening perspective, there’s techniques and technologies that might keep you from drowning, by simply raising the level of abstraction. Good frameworks help. Smart use cases certainly do. And even UML assists. And then there’s model driven development a.k.a. model driven architecture a.k.a. model driven engineering a.k.a. domain specific languages. Different names for generating code and other deliverables from a model. What model? To be honest, any model will do the trick. Business process models, use case diagrams, user interface models, domain models, and last but not least data models.

Empirical start

Eight years ago I was helping a customer set up the domain model for a help desk application. After that I started to build the software in ASP.NET. Having modeled all domain objects, their properties and their services, I was typing them out in C#. So, as any decent developer would do I wrote a code generator. That helped.

I suspect most code generation efforts have a similar empirical start. That’s probably why there are so many approaches to generating code. Some really high-brow, squeezing everything-and-the-kitchen-sink into a model, and then trying to generate the whole application. From front  to back. Or, at the very low and of the spectrum, inspecting the database, generating create-read-update-delete screens in a flat two-tier architecture.

Where’s the value?

Recently I was invited in a panel on model driven development, together with some academic and commercial experts. For starters, each of the panel members introduced their position briefly to the audience. This noteworthy event learned me two things. One: never allow four enthusiastic innovators talk freely on their innovations. The word brief isn’t in their vocabulary. Two: coming from a business background, I didn’t have a clue to what model driven development does in the academic world. A whole new spectrum of approaches met my eye.


So where’s the value in this? Following the good old Scrum adagio I’d say: it depends. Model driven development can be highly rewarding for projects. But I’ve also witnessed projects that made a terrible mess of it.

In my opinion, being successful at model driven development requires some preconditions to be met:

  • Embed approach. Successful model driven development projects share a single principle: it’s all in a day’s work. Model driven development is never a goal. It’s just a means to an end. Making better software faster. No guru’s, no heroes.

  • Allow changes. Projects go through changes. That’s a fact of life. Model driven development should never be blocking changes, but rather should stimulate creativity, by allowing projects to show quickly what effect new or changing requirements have.

  • Stabilize architecture. Knowing how to model, and where to generate what code is key. Set up a stable (layered) software architecture, pick frameworks that match it, and only then elaborate on code generation.

  • Be pragmatic. My general advice in life also holds for model driven development. Be pragmatic. Never overdo it. Don’t try to squeeze the whole world in your model. It’s not necessarily a bad thing to still have to write some code manually.


Having said all that, and having seen projects that very successfully apply model driven development, why is there still so much skepticism? After all, the paradigm really helps to deliver high quality at high productivity.

After witnessing both highly successful and extremely failing model driven development projects recently, I have given this some consideration. The vast majority of projects are in the middle of the wide spectrum of approaches. They run smoothly, being fairly practical. But it’s the failing projects at either end of the spectrum that draw the attention. Highly complex, slow moving, rigor projects on the one end, and oversimplified, bug-absorbing, underestimated projects on the other end. It’s no fun at either end.

No Jedi knight

My team and I have always adopted a highly pragmatic approach to model driven development, modeling smart use cases, applying domain driven design, run the model through our code generators (Tobago MDA) and we’re set to go. We do make better software faster.

Can life be this simple? It certainly can. We have applied this approach to all kinds of projects, and generated code in a variety of languages and frameworks, from Visual Basic to C#, from PHP and Java to Cobol. At the upcoming SDC, I’m going the check out a combination of Silverlight, .NET RIA Services, ADF and probably Fluent NHibernate. Should be fun!

To leave you with some words of wisdom (ahum). If there’s one thing I’ve learned from being successful at model driven development, it’s this: modeling and generating code should be everyday practice in your project. There’s no such thing as a “model driven development project”. There’s only software development projects. You don’t have to be a Jedi knight to steer a code generator. It’s all in a day’s work.

September 10, 2009. Keynote “Building better software faster”

Customer event Capgemini, at Capgemini Papendorp.

Together with a large customer Capgemini organizes a number of (non-public, sorry) knowledge sessions on Microsoft technology – aimed at developers, architects and project management. September 10 will be the first of those knowledge sessions, with talks on Microsoft Duet, Surface and Cloud / Azure.


Preceeding those interesting stories I will do an opening keynote. Was doubting about the topics to cover, originally thoughts of delivering a framework talk, but I’m also considering a story on model driven development.

Anyway, I might let the audience decide. Knowing myself (a little bit), since I only have 45 minutes to cover, I’d better pick a small subject.

Pragmatic model driven development. Part I. Code generation scenario’s

Note. This series of posts is also published as a Capgemini group white paper and published in Software Release Magazine (in Dutch, in two parts).

With the economy at a low point in time, organizations and project are clearly resetting their goals. Long term multimillion projects are being halted, in favor of short, agile projects, with feasible goals and good time-to-target. To realize these stringent goals, projects are striving for lower costs and higher productivity. On the one hand these goals might be reached by outsourcing, on the other hand standardization, industrialization and reuse could also contribute.

A long term promise in the field of increasing productivity and reuse is to handcraft less code, but to generate code from the project’s design or model. In general this is called model driven development

When is model driven development effective?

Although many alternative strategies exist towards model driven development, we feel that a pragmatic approach works best. The more theoretical an approach gets, the harder it is to apply it to projects. In this paper, we present such a highly pragmatic approach to model driven development. We model and standardize smart use cases and the domain model for a project, and generate code and other deliverables from these models using a straightforward tool set. This approach has proven to be very effective in many projects.

Model driven development can be effective when code and other deliverables can be generated rather than written or hand coded. Thus tedious repetitive work is avoided, such as creating web forms, user interface panels, domain objects, table create statements, service interfaces and even writing use case documentation. Developers can now focus on developing business logic, or tuning the user interface. We have witnessed very high productivity in projects that apply pragmatic model driven development. For example, a recent project (.Net) at a large Dutch government agency was realized in 20% of the time the customer estimated the project.

As it is also fairly easy to create new types of deliverables simply by investigating your existing code and derive template from this, we can save time and effort in many scenario’s and development environments. Model driven development has proven to be successful in (partly) generating solutions for various types of projects, including ASP.Net, Silverlight, SharePoint, Visual Basic Window Forms, Java, service oriented applications (.Net and SAP), and even back end functionality.

Moreover, as code generation is based on proven templates, generated code is of higher quality then hand written code. Thus, model driven development also contributes to lowering maintenance costs of delivered software. This effect is further increased because the documentation as presented in the model is directly traceable to the application’s code.

Last but not least, in model driven development, analysts and designer actively participate in delivering working software, as the models they help creating, are now directly converted into code. Model driven development is a collaborative scenario, where, especially in agile projects even end-users can participate directly in software development. To illustrate this, we usually model the smart use cases and the domain model that, underlie the software we produce, during interactive workshops with the end users, and generate working software either in these workshops, or shortly after.


Code generation scenario’s

Generating code from a model can be done in a wide variety of scenario’s, and with a even wider range of goals and deliverables to strive for:

  • Proprietary techniques. Traditionally there’s tools such as Oracle Designer and Developer or Cool:GEN that host both the model as the coding environment. Using these environment high productivity can be achieved, because a lot of assumptions can be made on the target environment. In general such development environments deliver highly proprietary models and code.
  • DSL’s. Domain Specific Language (DSL) are textual or visual representations of custom domains, for which specific modeling language can be defined, think of web service definition or even a language for defining the mortgages or life assurance domain. With DSL’s again has the promise of high productivity, if and only if, the target environment can be clearly defined, for instance in the software architecture and framework that are used.
  • UML. The Unified Modeling Language (UML) provides a set of techniques for modeling behavior and structure of applications. These standardized techniques, such as use case or class diagrams are used in projects around the world, however in different variations and dialects. Generating code or other deliverables from a UML model is highly possible, again if the target environment is well defined.
  • Database. With proper modeling techniques lacking, many tools take the approach of generating (parts of) applications from the database structure. Although this approach seems appealing and fast, there are limitations. The generated application will mimic the database, and thus will be very data-centric, instead of providing support for the work processes to be automated. Besides that, in the current era of service orientation and cloud computing, many application do not even have their own database.

June 2009

My talks in June 2009.

June 3. Agile software development in everyday practice.

Full-day seminar on doing agile projects for IT Works, Hotel Pullman, Diegem, Belgium. With guest speaker Stefaan van Royen, Mediamine. See

June 9. Pragmatic .Net development.

Full-day seminar on software architectures and patterns for .Net software development for Array Seminars, .NBC Nieuwegein. See

June 15 & 16. Smart use cases from front to back.

Custom two-day interactive workshop for information and business analysts of large Capgemini client at Capgemini Papendorp, Utrecht. Includes introduction of smart use cases, estimating smart use cases, smart use cases in service oriented architecture, testing smart use cases, domain driven design, agile, Smart / Scrum.

June 18. Mission impossible? Introducing agile in service oriented SAP projects.

Talk at Integrate Agile Conference with Twan van den Broek, Topforce, for the Agile Consortium Benelux, Claus, Badhoevedorp. I didn’t notice that I have a double booking until now… trying to solve it.

June 18 & 19. Pragmatic modeling using UML and beyond.

Fully packed two-day workshop on UML, modeling, smart use cases, requirements, domain driven design, model driven development and modeling in agile projects for IT Works, Hotel Crowne Plaza, Antwerp, Belgium. See

June 25. Navigating through the hypes. How frameworks can kill your projects, and how to prevent that.

Interactive talk on frameworks and how they can kill your projects at software architecture SDN Meeting in Hotel Houten, Houten. .

June 26. Agile anti-patterns. Yes, your agile projects can fail too.

Entertaining talk on how to make your agile project fail at the SDN Event in Hotel Houten, Houten.

Highway to hell? DevTweet: @mariannerd and @aahoogendoorn review code

The following conversation between Marianne and me will be published as our DevTweet column of SDN Magazine, issue 102.


Listening to Black Sabbath’s Master of Reality.


@aahoogendoorn Look at you… new avatar! Is that an AC/DC shirt?


@mariannerd Howdy partner! It is AC/DC all right. Your avatar new too? Something wrong with the old one?


@aahoogendoorn Nope, just a change in scenery! Like the project I’m doing. I’m asked to do a code review.


@mariannerd Cool! Whenever I’m asked to do a code review, the client always knows, or at least suspects, something’s terribly wrong.


@aahoogendoorn Oh yes… We have the suspect… Now it’s a case of getting the evidence … I feel like Columbo..


@aahoogendoorn You know the suspects from the beginning, but you still have to look for the evidence for conviction!


@aahoogendoorn So when you are asked to do a code review, what is the first thing you do?


@mariannerd The first thing I do? Ask the client what they’re hoping to achieve: do they actually want to know how deep the rabbit hole goes?


@mariannerd Next, I make a list of all things I should look at during the review. Architecture, domain, data access, layers, extensibility..


@mariannerd Security, authorization, reuse, code copying (especially in VB), way of working, documentation, design, quality of coding.


@aahoogendoorn So far so good!


@mariannerd Rule #1 in code reviews: more time means more detail.


@aahoogendoorn Code Reviews are fun! No deadlines. just looking at somebody else’s code.


@aahoogendoorn … Oh and telling what’s wrong with it… I must say this is the first time I get such an assignment.


@mariannerd. You know, there’s so much horrible code out there, we could do code reviews for the rest of our lives.


@aahoogendoorn Well a lot of this stuff is subject to opinion… 100 developers, 100 different code for the same functionality…


@mariannerd Yes true, but some code is definitely worse than other code. And believe me, I’ve seen some bad coding in my time.


@aahoogendoorn Any examples?


@mariannerd Examples of bad code? How many do you need. Check out this old blog post of mine (in Dutch).


@mariannerd. Think of SQL statement in web pages, or of a single class that handles 50% of all functionality.


@mariannerd. Or think of the same business rule implemented multiple times on different locations, in different ways.


@aahoogendoorn One of the things I came across: internal web application: authentication by doing a LDAP query to see if the user exists.


@aahoogendoorn Haven’t they heard of Windows Authentication in IIS? They didn’t even check if the user was enabled or disabled… :-S


@mariannerd Haha, nice one. I once audited the enterprise web portal for a very large international company where ALL communication …


@mariannerd between front end and back end went through one single class. Imagine the effect of a single change..


@mariannerd Sometimes, it gets really bad. Code a whole company depends on, which is so bad, that productivity will definitely be below zero soon


@mariannerd Anyway, I love being asked for code reviews. It gives the opportunity to help improve the quality of applications.


@mariannerd. That is, if they follow up on your advice from your code review. Unfortunately, that is not always the case.


@aahoogendoorn Well maybe it’s not needed… Or they just want to know the risks and are happy to take them!


@aahoogendoorn Which could be the outcome of a code review. It’s not good, but far from worse.. And it may be fixed with a couple of quick wins.


@mariannerd. Well yes, that could be the outcome. Maybe I’m to idealistic about writing good code. If it ain’t broken, don’t fix it.


@mariannerd. But I just love clean code…


@aahoogendoorn …. But even bad code can function.


@mariannerd My favorite example: an ASP.NET web site that was never compiled by the developers. They just ran it from the browser. Great stuff!


@mariannerd. As a consequence, of the over 40 pages in the application, only 6 compiled (the ones they visited running it in the browser)…


@aahoogendoorn LOL "we got a live one here!". This business application compiled at runtime? No test cases just put it in production!


@mariannerd. And then things can get pretty messy. Especially when your poor company lives of this software.


@aahoogendoorn That is the whole point isn’t it.. Developers just start coding without a plan, or knowing best practices.


@mariannerd Yes, a lot of developers code without having a decent architecture, without patterns, without layers – but with best intentions.


@aahoogendoorn Oh yes, best intentions… The road to hell is paved with good intentions…


@mariannerd. No stop signs, speed limits. Nobody’s gonna slow me down. Highway to hell. AC/DC# ?


@aahoogendoorn Nope… 4 minutes by Madonna LOL.


@mariannerd. Madonna? Girl you need a music review instead of a code review!


@aahoogendoorn ….I guess even bad music can function. ;-)