Category Archives: Smells of bad code

A book on pragmatic software architecture, patterns and frameworks?

Posted on by
8

One of the major items on my wish list – that is on the professional half of it – is to write a book that displays my ideas on software architecture, patterns and frameworks. Yes I know, there are many books on software architecture, and there are many books that explain patterns, and yes there also are a lot of books that show you how to work with framework A, B or C.

So you would say, why on earth would you want to write a book on these subjects? Well there’s three major reasons. First, there’s not a lot of books out there that combine all these subjects into one single coherent story that will actually help you to write your applications better. Second, maybe I’m a bit arrogant on this, but I feel like I have something to all the stuff that’s out there. And last but not least, I finally need to get this stuff out of my head! Maybe ambitious, but let´s see!

Order from the menu

To be honest, you might like or not like all of the ideas in this book, or even may totally disagree with some of them. Actually, you probably will. But on the whole, I hope this book will be able to inspire you and illuminate you in how to build software. It´s often a matter of taste. So consider this book as a menu. Just order from it what you like. You don´t need to copy the C# and .NET code examples from the book, but rather I hope that use can use them to shape your own ideas on software architecture, frameworks and patterns. Take from it what you like, and forget about the few things you don’t like. 

A first step

What’s the first step towards writing this book? I’ve been teaching about software architecture, patterns and frameworks for .NET for quite a number of years, and the material from these courses will be a good start, similar to the way I shaped my book on UML – from iterating over the material I had for my UML courses.

PIC091019003 

Along with the course material comes the work I’ve done in projects, and as a result the work we (the core team) do on our ever-evolving and improving ADF.NET framework.

Architecture and frameworks

So here’s the overview of the material in the software architecture and patterns course:

  • Introduction. All the usual bla bla and thanks you stuff.
  • How to set up your software architecture? A mild and brief introduction. Thinking about layers, elements in layers,  collaborations (yes CRC). And of cause you can not start without summing up some of the good practices, such as
  • (Software architecture != List<Framework>). How people mix up architecture and frameworks.
  • How frameworks can kill your project. It’s all about dependencies guys. This chapter will be a write out of my talk with the same name.
  • Some patterns to help avoid getting killed. Explaining the different variations of layer super types, my fine descriptor pattern, and the use of dependency injection and the manager-provider pattern.
  • Glue 1.0. My first framework. Short introduction into setting up a minimal framework, using your architecture and the above patterns, minimizing dependencies between your application code and the frameworks you use. It should provide you with the glue to keep your “regular” developers in the loop.
  • Extension methods and fluent interfaces. Have got a bit (not all by far!) to say on how to use them to enable your application developers to code easier and more natural using your first framework.
  • Lasagna and ingredients. What layers would you need in your application? Suggesting presentation, process, domain and data/services. And suggesting a lot of elements in the different layers.

Presentation

In the next chapters I will slowly go through the individual layers. First, let’s investigate the presentation layer:

  • Panels and lists. The basic patterns of presentation layer elements. And a straightforward implementation of a user interface independent panel. Just for the fun of it.
  • The master of detail. Introducing some typical user interface patterns, such as manage, select, search, master-detail, list-detail and the effect of those patterns on your architectural and Glue 1.0 framework requirements.
  • MVWTF. Looking at the different variations in model-view patterns, and discussing the relevance. But briefly, there’s enough said on this stuff.
  • Binding and persisting. Coupling and de-coupling your models, view-models, domain objects, whatever to and from the user interface.
  • The view-model. Sense and non-sense of view-models.
  • Validations. Things to validate and things not to validate in the user interface.

Process

Next the process layer gets a rub:

  • Why do I need a process layer? Explaining the least well-understood layer in application architectures.
  • An brief introduction to smart use cases. Still an excellent unit of work, implementation and testing for projects. This chapter will follow the lines of my presentation on this particular topic.
  • Implementing smart use cases. Introducing the task pattern, and re-iterating the manager-provider pattern. Great stuff I think! Also re-visiting the MVWTF patterns again. 
  • Unit and regression testing smart use cases. How you can write your own extensions to regular unit test framework to allow regression tests over your smart use cases.

Domain

The layer it all revolves about:

  • About being domain driven. Design, code and test, do it domain driven. Now I’m not going to repeat Eric Evans’ book here, but I do repeat (briefly) the basic concepts that derive from his work. Think of entities, repositories, factories, value objects and services.
  • Augmenting your domain. However, we are using some additional patterns in our projects that are useful patterns. Here I’ll discuss the smart reference pattern, revisit value objects, and talk about cached domain objects. I might even introduce you to search objects.
  • Business rules and validations. How do you write and where do you place your business rules, and what validations do you execute in the domain layer?
  • Independent state. Domain objects, or entities, have identity and state. This state can come from a lot of place – not all being SQL Server. So the big question here is: can I keep my domain objects independent of how we get and set its state. Well yes you can, hence the internal state patterns jumps in.

Data, services and the outside world

All the way down to the bottom, in the cellar of your application, lies the data / services layer:

  • Does the data layer really exist? Hey weren’t we using NHibernate or Entity Framework? So why do we need a data layer, and if so, what is in it?
  • Map and wrap. When querying data sources it is very likely that you will need to provide some sort of mapping from your world to the outside world. I’ll show you some simple patterns of to achieve this mapping, allowing you to wrap your domain objects around the outside world’s objects.
  • Creating queries. Again, do you really need to implement a query patterns. We do have LINQ do we? Well yes, but LINQ does not cover all your possible sources of data – a lot, but not all. So a brief introduction of the query pattern – and some implementation aspects might not be a bad idea.
  • On the way out. Somehow you will need to reach out to the outside world of your application. Virtually the outside world can be just about anything. A (set of) databases of course, but what about OData, JSON, plain or not so plain XML, restful or restless web services, Twitter, Entity Framework, NHibernate, Facebook, you name it. The gateway pattern should help you here.

Concluding

    Mildly put, this little blog post could well be the introduction for this new book – except for the thank you notes. Do you miss anything, or already agree or disagree? Want to help annotating or reviewing the manuscript in progress? Don´t hesitate to become a part of the writing process. Please comment here!

Please vote for my Microsoft Mix 2011 proposals!

Posted on by
1

From April 12-14 the next edition of Microsoft’s MIX Conference will take place in Las Vegas. I’ve sent in two proposals for the Open Call. Today heard that both proposals made it through the first cut, which means they’re open for public voting (you don’t have to be registered). It would be great if you would cast your vote for my proposals on how smart use case can drive web development, and on how frameworks can kill your projects.

300x250_Mix11_011011_US_b

Proposed talk 1: How smart use cases can drive ASP.NET web development

Use cases have been around for many years describing the requirements of software development projects. By developers, use cases are often seen as too abstract and too complex to develop code from. That is, until now.

During this interactive talk speaker Sander Hoogendoorn will demonstrate how to model, generate and build smart use cases. This great technique allows projects to model use cases at a much more pragmatic, and low-granular level, that can be implemented straightforward and directly into our applications, such as ASP.NET or Silverlight web application. The speaker will introduce both the positive impact smart use cases have on your layered software architecture, as well as the design patterns required to implement smart use cases. This talk comes with many real-life code examples.

Proposed talk 2: How frameworks can kill your projects

When it comes to .Net development, more and more frameworks enter the market. Both from Microsoft and from open source. think of ASP.NET MVC, Castle, WF, Entity Framework, Unity, Linq2SQL, ADO.NET Data Services, WCF, nHibernate, Spring.NET, CSLA, NUnit, Enterprise Library or ADF.

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 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 totally different? These and many more everyday problems will cause your project to come to a halt, or at least make you perform serious refactoring.

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 will present models of layered architectures, and apply bridge patterns, managers-providers, dependency injection, descriptors, and layer super-types.

Of course, the speaker will illustrate these insightful patterns with lots of demo?s and (bad) code examples using blocks from Microsoft?s Enterprise Library, NHibernate, Log4Net, and the Entity Framework. Delegates benefit by learning how to improve the structure and quality of their software architecture and code, and how to avoid the pitfalls of applying frameworks to .Net software development.

Navigating through the hypes, Software architectures and patterns to help avoiding your projects to crash – this year’s DevDays talk.

Posted on by
Reply

Good to hear that I’ve made the program of this year’s Microsoft DevDays. Will be a challenging talk on software architecture and patterns, titled just like this blog post. Here’s the description. Hope you like it.

Navigating through the hypes, Software architectures and patterns to help avoiding your projects to crash

When it comes to .Net software development, more and more frameworks enter the market. Both from Microsoft and in open source. Just think of all the very useful frameworks, such as ASP.NET MVC, Castle, WF, Entity Framework, Unity, Linq2SQL, ADO.NET Data Services, WCF, nHibernate, Spring.NET, CSLA, NUnit, Enterprise Library or ADF.

Once a project chooses to apply one or more frameworks, trouble begins. What if you require additional features that aren’t implemented in the framework? What if you decide that another framework would have been better and want to switch halfway 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 totally different? These and many more everyday problems will cause your project to come to a halt, or at least make you perform serious refactoring.

During this highly interactive talk Sander Hoogendoorn, principal technology officer at Capgemini, chief architect of Capgemini’s agile Accelerated Delivery Platform, and member of Microsoft’s Visual Studio Advisory Board, will demonstrate pragmatic software architectures and patterns that will help your projects to stay away from framework problems, and how to keep your code independent of framework choices. In his well known slightly ironic style Sander will present different models of layered architectures, and explain and use bridge patterns, managers, dependency injection, descriptors, and layer super-types.

Of course, the speaker will illustrate these insightful patterns with lots of demo’s and (bad) code examples using blocks from Microsoft’s Enterprise Library, nHibernate, Log4Net, and the Entity Framework. Delegates will benefit from this talk by learning how to improve the structure and quality of their software architecture and code, and how to avoid the pitfalls of applying frameworks to .Net software development.

The merits of two-tier architecture. Domain driven development in the distributed era. Episode II

Posted on by
Reply

Go to episode one.

So now you’re stuck with this two-tier architecture. Is this a problem. Well, not yet. However, it can become a huge problem, and it has become a huge problem in many, many client / server applications, in a vide variety of technologies, including several types of (legacy) web application technologies.

The truth is out there

The problem with this architecture again is fairly simple. There is no single point of truth. Business logic is scattered. Consider this simple piece of business logic below.

if (StartDate < EndDate)
{
   ...
}






This code is now in the database, to keep the database from getting harmed. But it is also copied into one of the forms in the application, preferably on an event that is fired when the user tabs out of the field StartDate from, let’s say a Contract.


Eventually, there will be someone on the team of developers who is going to build another form that involves manipulating a Contract. It could be yourself, or any of the other well-educated developers, but there’s always someone how will copy-and-paste the business logic from the other form to the new one. And from that time on the truth is out there. Somewhere. After a while, you will end up with an application that looks like this.


image


And you might not even see that, because it happens over time. For instance, much of this copy-and-paste activity will take place after the application is deployed and it enters maintenance mode. Especially when the boys and girls doing the maintenance were not on the team that built the software.


Customers changing their minds


Still, this doesn’t have to be bad. It will become bad when something peculiar happens: the customer changes his mind on the business rule. Now, I know, that never happens on your projects, but on mine it did and it does. On average, requirements will change about 20% to 25% during the project. And there you go. Let’s say the customer just thought of the fact that the previous rule must be altered. Just a very small change, isn’t






if (StartDate <= EndDate)


{


...


}






So the boys and girls in the development or maintenance team start looking for the locations this business rule applies to. Of course, there is hardly any documentation, so they start searching the code. And you know what, they will find occurrences of the business rule and fix them. But, that’s Murphy for you, they will likely not find all the occurrences. The applications will now look like this.


image


And that’s where client / server fails. Miserably.

					

		
		
	


				
					
	

		

						
So much to write, so little time

			
						

				Posted on   by  			

			
						

				3			

					


				

			

It’s too bad there’s only 24 hours in a day. There are so many ideas in my head that I still have to write down, that I have to make a (short) list now to keep my head from exploding.


So here it is:


    

  • White paper on how to do agile SAP projects using smart use cases.
    • 

  • Article on applying smart use cases in BI project (started).
    • 

  • White paper on agile accounting models (80% done).
    • 

  • White paper on my agile methodology Smart.
    • 

  • Book on agile / Smart in everyday practice (lay-out done). Have to find publisher.
    • 

  • Book on software architecture and patterns for .Net projects (started). Need to find publisher.
    • 

  • White paper on pragmatic model driven development.
    • 

  • Wiki page on how to use Tobago MDA.
    • 

  • Article on pragmatic model driven development in Java (with Rody).
    • 

  • Article on Descriptor pattern
    • 

  • Article on Smart Reference pattern (80% done).
    • 

  • Blog on agile mediocrity.
    • 

  • Article on application migration using smart use cases and the Accelerated Delivery Platform (started).
    • 

  • Ugly blog on the hype of cloud computing, following and extending the hypes around service orientation and component based development.
    • 

  • White paper on distributed agile software development.
    • 

  • Book on project anti-patterns (lay-out done).
    • 

  • White paper on our three references architectures, identifying all types in the layers, and their responsibilities.
    • 

  • Update the wiki with Smart 3.0 (30% done).
    • 

  • White paper on level of ceremony in agile methodologies (30% done)
    • 

  • Wiki page on mixing Scrum and Smart.
    • 

  • Wiki page on splitting smart use cases to work items.
    • 

  • Wiki page / article on testing smart use cases (80% done).
    • 

  • Newsletter item on visit of .NET PAC in Redmond.
    • 

  • Book on smart use cases.
    • 



And moreover (added February 6):


    

  • White paper on agile for software product development.
    • 

  • White paper about implementing agile smart.
    • 

  • Blog on questions raised during recent discussion on implementing agile at a large international bank.
    • 

  • Blog post(s) on going from Twitter API to service oriented software.
    • 



So help! Any votes or assistance offered?


For more information around these subjects see: www.accelerateddeliveryplatform.com

					

		
		
	


				
					
	

		

						
Why do you need a layered architecture?

			
						

				Posted on   by  			

			
						

				2			

					


				

			

The first business software I wrote professionally – that is, got paid for – was a set of small and similar calculation applications. I wrote these in the pre-Windows era in some version of Turbo Pascal. And no matter how ignorant I still was about good software architecture, these small applications already had a notion of layered architecture. And though the term design pattern wasn’t even coined back then, many people consider layered architecture to be one of them. Personally I think that writing software in a layered architecture is more of a way of life. I wouldn’t know any other way to build business software. Would you?


Why are layered architectures so useful? Well, first and most of all they allow you to distinguish and distribute the responsibilities that your application, your code has to deliver value to the end user. That is, the user interface does not contain components or elements that handle business logic. Business logic resides in a separate layer. A data access layer does not have anything to do with presenting the data, it deals with the database.


Layered (food) architecture


And if your thinking this is trivial, please note that there are hordes of developers who still write database connection strings and queries in each web page they develop and who still validate the same business rules in each web page they data is presented. You’re not alone.


Distinguishing and distributing responsibilities – if done correctly and pragmatically – will deliver a number of benefits to your projects:


    

  • Easier to understand. Code will be easier to understand, not only for the developers who wrote it, but also for the poor bastards who have to maintain the code once delivered. Code is just easier to maintain when you know where to find it. Code becomes traceable.
    • 

  • Easier to write. Have developed applications for over twenty years, I think I’m entitled to say that a day’s work is more fun writing software under architecture. It’s cleaner, more serene.
    • 

  • Easier to test. Although I personally consider testing software not the most fun, I do think that software that is written under architecture is far more modular. This makes it possible to define independent unit much better, which makes unit testing easier and better. In fact, testability is one of the main motives to define your layered architecture. Design it with testing in mind.
    • 

  • Easier to extend. Last but not least, having a layered architecture in place will allow you to add new features, or change the current features more easily. Adding a new use case to the system, or extend the business rules on a particular domain object much harder if the process or business logic is spread throughout the code.
    • 



Need I say more?

					

		
		
	


				
					
	

		

						
Why do we need software architecture?

			
						

				Posted on   by  			

			
						

				3			

					


				

			

Over the past twenty or so years I have been involved in many software development projects, code reviews, and software factory implementations. Although I had stretched the virtues of good software architecture for decades, it wasn’t until a series of recent event, that I really started re-valuing of having a sound software architecture in place. And to me a well-defined software architecture merely describes the patterns used, the layers applied, the types of classes in these layers, and how they collaborate. Primary goal would be to create structure and a clear separation of concerns in your application code.


Code is like ivy


In October and November, I was running a code audit on a 1.4 million lines of code ASP.NET web application, the second large audit I did in a short period of time. Both products where web applications that were targeted at big audiences, and that were meant to last for a long time. And in both cases the software architecture was set up really bad. In one example, I couldn’t even discover a decent software architecture through the code. In just three years this application had grown from a small web application to an enterprise web portal,  and a few dozen developers, partly external from the company, had written code in a wide variety of styles. With no architecture in place, the code grew like ivy on a moisty garden shed, resulting in poor maintainability and low productivity in adding new features to the product.




Midst November, I found myself in Barcelona, visiting the Microsoft TechEd conference, where a number of new frameworks were presented – although most of them still in beta. Some of these framework already made their way into full swing projects, one the largest run for one of our Belgian customers. Looking at the presentations, and talking to developers, it occurred to me that a lot of people have their software architecture dictated by the frameworks they apply.


Just think of this. One of the developers I talked claimed to have a good software architecture just because he was using the ASP.NET MVC framework. My vision however is different. It should simply be the other way round. You have a sound software architecture in place, that expresses the business needs and the technical concepts to implement these business needs. Then if you’re interested in applying a particular new framework, you should only need to map the concepts of that framework, say ASP.NET MVC or the Entity Framework, to the concepts in your software architecture. And if it fits, use it. And if it doesn’t either don’t use it, or encapsulate it, so that it will fit in.


Benefits of a sound software architecture


So concluding, if your organization has a software architecture in place, this will offer some rather relevant benefits, which include:


    

  • Higher productivity. It is easier to add new features to existing software, since the structure is already in place, and the location for every new piece of code is known beforehand.
    • 

  • Better code maintainability. It is easier to maintain existing software, as the structure of the code is visible and known, so it’s easier to find bugs and anomalies.
    • 

  • Higher adaptability. New technical features, such a different front ends, or adding a business rule engine are easier to achieve, as your software architecture creates a clear separation of concerns.
    • 

  • Hype agnostic. Last but not least, it will allow you to see hypes and fads in the industry – or which there are a lot – in the light of your current structure, and to fit these hypes and fads in if so required.
    • 



So?


So why is it so many organizations and project to not adhere to having such a software architecture in place? It’s beneficial and it doesn’t require a big up front state of art research & development. Just common sense and best practices.

					

		
		
	


				
					
	

		

						
Core [in Dutch]

			
						

				Posted on   by  			

			
						

				Reply			

					


				

			

Het is maandagmorgen. Er schijnt een waterig zonnetje over Ede. Ik parkeer mijn auto op het parkeerterrein van de Reehorst dat verlaten oogt bij de start van de nieuwe werkweek. Ook vandaag is de Reehorst het toneel voor een Software Developers Event. Één sessie in het bijzonder heeft mijn interesse: Addressing non-functional requirements with aspects.


Waarom nu juist deze sessie? Het verhaal gaat over PostSharp, een aspect oriented framework, en wordt gegeven door Gael Fraiteur, de bedenker van het framework. PostSharp is geschreven in C# en is een hele cleane, voor reguliere developers begrijpbare implementatie van aspectoriëntatie. Nadat in mei op een conferentie in Zurich al een presentatie over PostSharp had bijgewoond, schreef ik op een terras meteen al mijn eerste aspect. Heerlijk eenvoudig!


Frameworks. Ik kan er niets aan doen. Ik hou gewoon van frameworks.  Heerlijk om te zien hoe developers, teams en project hun generieke problemen oplossen. Of eigenlijk, zoals ze keer op keer dezelfde problemen oplossen. Want wie maakt bijvoorbeeld het id aan van een nieuw domeinobject? De applicatie of de database?


Trechter


Soms levert het kijken naar code uiterst aangename middagen op, zoals bij een recente code audit die ik samen met een collega uitvoerde op een enterprise portal voor een wereldwijd bekend merk. Laat ik het anoniem houden. Een schoolvoorbeeld hoe het niet moet. Meer dan een miljoen regels code. De ontwikkelaars hadden getracht een servicegeorïenteerde software architectuur te implementeren. Waarschijnlijk op aanraden van de architectuurafdeling van het bedrijf. “Wij ontwikkelen hier altijd onder architectuur. Een service georïenteerde uiteraard.” In deze portal betekende dat alle bedrijfsfuncties vanuit de webpagina’s als web service werden aangeroepen. Op zich nog niet verkeerd, al gaf het deployment model in te uitgebreide documentatie geen aanwijzingen voor de noodzaak hiervan. Bijzonder fraai was dat al deze services – 354 in totaal – allemaal op een en dezelfde klasse waren geschreven. Met recht een trechter.


Vorige week verzorgde ik in Antwerpen een tweedaagse training in het pragmatisch toepassen van UML. Ik kom graag in Antwerpen. Fijne terrassen, prima bier. En zo belandde ik aan het eind van een hectische eerste cursusdag op een terras op de Melkmarkt met twee cursisten.




Cafe Pelikaan op de Melkmarkt in Antwerpen




Beiden werken voor een klein bedrijf in Utrecht dat software ontwikkelt voor zorginstellingen en ziekenhuizen. Deze software, zo verhalen de twee functioneel ontwerpers, wordt ontwikkeld in PHP. Ooit gestart door twee techneuten met een goed idee voor een onontgonnen markt en voldoende kennis van PHP is het bedrijf nu vijftig man groot. Maar bij de start gebeurt het! Je schrijft je eerste code en ontdekt dat sommige software herbruikbaar kan zijn. “Hé, we hebben een object Patient en een object Operatiekamer en die worden beide opgeslagen. Laten we dat isoleren.” En voor je het weet ontwikkel je je eigen framework. Met alle bijzondere principes en eigenaardigheden vandien.


Jaloers


Het ontwikkelen van frameworks vergt een heel eigen vocabulaire, patterns en best practices. Al eens naar het patroon layer supertype gekeken? Ook model-view-controllers zijn er in overvloed. En gebruikt niet ieder project een object relational mapper? En of dat nu Microsoft’s Entity Framework , Hibernate of wellicht een eigen implementatie is? Alles is mogelijk! En wellicht maken uw projecten gebruiken maken van dependency injection – het mechanisme waarmee pas op runtime afhankelijkheden worden gelegd. Gebruikt u ObjectBuilder of zijn opvolger Unity? Of dan toch liever open source? Probeer Windsor. Ook bij Microsoft lusten ze wel pap van het schrijven van frameworks.  Microsoft – of meer specifiek Scott Guthrie – heeft zich onlangs alweer van zijn beste kant getoond. De beta van Silverlight is de deur nog niet uit, of Scott verlustigt zich al aan zijn volgende framework, getiteld ASP.NET MVC.


Soms ben ik daar stiekum jaloers op. Op de ontwikkelaars van het framework in PHP in Utrecht die daar een op ziekenhuizen gerichte eigen variant van Outlook mee ontwikkelen, als op Gael Fraiteur met zijn PostSharp, maar ook op Scott Guthrie en de andere bedenkers van frameworks bij Microsoft.


Catchy


Er is namelijk niets leukers dan het schrijven van een nieuw framework. Gewoon van scratch af aan. Verzin een catchy naam. Django of Zend. Start met een nieuwe solution in Visual Studio en maak je eerste items aan. Zou ik nu starten, dan zou ik eerst een assembly Core en een assembly Domain aanmaken. En dan een interface IDomainObject definiëren en een klasse DomainObject, die deze implementeert. Met een property Id schat ik in – een value object uiteraard – en een property Title, zoals ook het NakedObjects framework doet voor het eenvoudig representeren van domeinobjecten. En voor de zekerheid  overschrijf ik ToString() zodat deze dan mooi Title retourneert. Misschien begin ik vanavond nog wel!


Maar ook voor frameworks geldt: er is een tijd van komen en een tijd van gaan. Op een gegeven moment is de rek uit je framework. De ooit briljante ideëen zijn ingehaald door nieuwere frameworks, die hipper zijn, open source, en uitgebreid gedocumenteerd. Wat te doen? Een complexe keuze. Ontwikkel ik verder aan mijn eigen framework? Implementeer ik daarbij nieuwe features die andere frameworks al kennen? Hoeveel aanpassingen moet ik daar voor maken? Of ontwikkel ik een nieuw framework, dat al deze nieuwe features al standaard in zich heeft, en natuurlijk beter is dan wat de markt nu te bieden heeft. Of stop ik helemaal met het opzettten van frameworks, en ga ik alleen gebruik maken van frameworks van anderen? Of stoten we meteen maar al het ontwikkelwerk af naar India?


Laat ik me er voorlopig maar niet over buigen. Een tijd van gaan? Inderdaad. Tijd om Word af te sluiten en Visual Studio te openen.


Published in SDN Magazine, July 2008.

					

		
		
	


				
					
	

		

						
Smells of bad code [1]

			
						

				Posted on   by  			

			
						

				Reply			

					


				

			

Can’t help it. Looking at someone else’s code is just plain fun. Especially when it’s not that well architectured. It seems that I keep running into nice fragments of how not to code. Well, to be honest, my colleagues tend to help out, and send me all kinds of code examples.


Have a look at the tiny fragment below.


If HttpContext.Current.Session("UserID") <> "obama" And HttpContext.Current.Session("UserID") <> "h.clinton" Then Response.Redirect("../../default.aspx")


Brilliant, isn’t. Of course I changed the names, as you might expect. This is a cruel example of authorisation. At first, the developers (being the two persons who do get authorized) will probably have thought: this is ok for now, we’ll refactor it later before the application gets deployed.  Unfortunately, they forgot. This code was found in a web application in production. Moreover, it had thousands of users. Now imagine the trouble the people administrating the application will have. “Why do I have to login as obama? Who is he anyway?”


There’s another explanation. Although less desired. It’s that the developers just didn’t know any better that to write the user name in a session variable named UserID. Let’s hope this scenario is not the case. It would scare me to see that this could well be exemplary for the quality of the code.