Category Archives: Anti-patterns

The Waterfall Dentist Anti-Pattern

Posted on by
Reply

Believe it or not, but I have a confession to make. I’m currently in a pure waterfall project. It’s my first in many, many years and despite the fact that I love the technology, I don’t like our way or working it a bit.

During the first phase of this project we are trying to deliver twenty functional work items. All of these twenty work items are analyzed first, then reviewed. After all review comments have been processed, all work items are designed. And again reviewed. After all review comments have been processed again, the developers start constructing them. And once they finish the testers have a go at the software produced.

Yes, I know this is efficient nor effective. And yes, the testers find lots of defects that could have easily been prevented using an iterative approach where we jointly work on a single work item, and only after it’s finished move on to the next. But we just don’t. And the delivery date is nearing. As a result, at the delivery date we will likely deliver twenty half-baked work items, instead of delivering maybe ten or twelve complete work items. It’s a choice.

End of discussion

You could say that the discussions about the chosen approach I have with the project manager are vivid. At the very least. “No, we’re not going to do agile,” he clearly states. “I don’t care if we call it agile or not,” I respond, “But the way we are working now is simply inefficient.” Personally I really don’t care if projects are tagged as agile, Scrum, Smart, RUP or even waterfall. I just dislike inefficient processes. “This approach is easy to explain to the client,” the project manager continues, “So we are going to stick to it. End of discussion.”

And then coming out of my girlfriends’ apartment building this morning I saw this car in the parking lot. It occurred to me immediately. We are waterfall dentists.

2012-08-18 12.42.59

Imaging you’re a young dentist, fresh out of dentistry school, and you are starting a new practice. Why on earth you would name it The Waterfall I don’t know, but twenty new patients are hurdling up to be treated. Being The waterfall dentist you use an appropriate approach. During the first week you examine all twenty patients. During the second week you commence to the first part of their treatment: drilling holes. Then in the third week, all twenty patients come back and have the holes filled. In the fourth week all patients return again for a last check-up. Just testing if all holes are filled properly. Finally, in the fifth week you get to send twenty bills to twenty happy patients. Project done. Next project.

Good bookkeeping and new patients

Doesn’t that sound good? This approach resembles my current project in great detail. So why is it, although this model is easy to explain to patients, no dentist in the world would even slightly consider to apply it? Well, first of all, your patients don’t like to walk around with unfilled holes in their mouths for a least a week. Second, your patients will have to come in to your office four times, and you will have to do pretty good bookkeeping to remember each patients details when they return. If you would have filled a patients tooth right after you’ve drilled a hole, this need for documentation and good memory wouldn’t have been necessary. Moreover, what if a new patient comes in during the second or third week with a terrible toothache? You would have to decline him saying: “Sorry, I don’t take additional work now,” advising the new patient to come back after all current patients are serviced. It’s the vicious change request. And what if you become ill during? Your whole schedule will certainly slide. As a result, none of the patients will have been fully serviced at the end of the scheduled period, leaving them in uncertainty about when you will deliver. Basically, you will loose your patients as fast as they hurdled up. And you won’t be able to send any bills.

I could probably spent another two posts in explaining why the waterfall model isn’t applied by dentist anywhere in the world. But I won’t.

We just might

Dear project managers, despite the fact that the waterfall model is so easy to explain to clients, that doesn’t make it any more effective or efficient. Armed with The Waterfall Dentist Anti-Pattern, you can explain iterative, or agile, approaches to your clients just as easy. In fact you can even service your clients better, as they may send in new urgent patients during the project, and you will be able to service those patients early. And even though you may turn ill during the project, servicing the patients one by one, rather than in a returning batch, you can actually fully service a large number of them within the designated timebox, instead of having serviced all of them half when the deadline approaches. I would much rather be able to send bills to fifteen out of twenty patients, then not being able to bill at all.

So where’s my current project standing? Well, just like The waterfall dentist might actually serve twenty patients during the current phase, we might actually deliver all twenty work items. But I wouldn’t bet my gold teeth on it.

What could the Dutch football learn from agile?

Posted on by
3

After a series of very disappointing games the Dutch national football team was eliminated during the preliminary rounds of the European Championships. Comments weren’t mild. The most heard comments largely focused on the lack of team spirit and mental fitness. Not uncommon to Dutch national football teams.

Earlier this week an interesting broadcast of the Dutch sports program Studio Sport included a discussion between some football players and the successful Dutch field hockey coach Mark Lammers. The latter stated that teams perform much better if the players share responsibilities. The Dutch football players at the table responded to this statement that this might work well in a modern game such as field hockey, as one the players said that he even saw it working in his daughters field hockey team, but that football is by nature a very conservative game, with lots of high profile media attention and that in this game the players should just execute the coaches orders.

I couldn’t help but watching this from an agile view. Clearly Mark Lammers would do well managing an agile software development project. Even though responsible for the team as a whole, he insist on giving the players the liberty to collaborate. Pretty similar to how agile project managers guide their project teams. Funny enough the Dutch football players ridiculed his ideas, and repeated that the players should just follow orders. That the game would become total chaos otherwise. Having seen the Dutch team playing, chaos was a actually a word that came to mind. And following up the coaches orders wasn’t part of it.

It’s actually the very same mockery agile has received from traditional managers over the years. Yes this agile stuff might work in small projects (such as the one football players daughters hockey game) or in fancy mobile projects (field hockey is a modern game), it doesn’t work in large, complex, high profile projects. Software development is a highly conservative game. It should not be bothered by this letting-the-players-share-the-responsibilities-in-the-team mumbo jumbo. Football players just execute their individual tasks. Just as analysts, developers and testers do in important software development projects.

Lammers had a good argument. Wouldn’t they agree that if players had influence and saying in what would be the best task, or how to execute it in the best way, they would simply run harder and even collaborate better as a team? The football players looked at him like they saw water burning. Lammers just couldn’t get through to them. Similar to the many discussions I’ve had about agile with traditional managers. It is the team that does the job. Not the individual players.

Doesn’t it just amaze you who unhappy highly appreciated players like Robin van Persie, Klaas Jan Huntelaar, or Wesley Sneijder with their respective tasks, and hence didn’t make it as a team? Wouldn’t that be similar to having Erich Gamma, James Gosling, Scott Guthrie and Anders Hejlsberg as the team of programmers in a project, and than have the project managers handing them out individual tasks, and denying them any influence in the project?

Much to my demise, one of my current projects is actually a waterfall project. Although I am one of the most seasoned guys (resources to the project manager) on the team, and have the role of software architect, the project manager insists on defining individual tasks that I should perform. There’s a whole list. I even book hours on individual posts per task. The horror.

So even though I’m in the role of overlooking the technology in the project, I’m actually constructing individual parts of the framework and the application. Solo. Now to me that is not a very motivating situation. Collaboration isn’t stimulated. So there’s little between the members in the team. In my opinion the project is running in a highly sub-optimal mode, where everybody delivers individual tasks, and then throwing the result over the wall to the next person. The project could be executed much more efficiently if we could operate as a team. With shared responsibilities. Not as a disjoint set of qualified individuals.

Back to the Dutch national football team during these European Championships. Wouldn’t you agree that this is actually a very good description of the whole thing? A bunch of highly qualified individuals all executing individual tasks that didn’t like to do? Wesley Sneijder clearly didn’t like his role as a left winger. And neither did Arjen Robben like his role. Hence they executed them without flair, without efficiency, and most of all without operating as a team. They were executing individual tasks, and throwing the result over the wall to the next person.

And still, at the end of the television debate, the field hockey coach was unable to convince the conservative football players. They clearly totally missed what he was talking about. Even when the question was posed whether the players are subordinate to the coaches tactics and plan, of whether it might be better to form a team that best fits the players qualities, they chose to stick to the plan. To put it in the words of the agile manifesto: they valued following a plan over individuals and interactions.

If only the next Dutch football team would learn from agile. And if only traditional project managers would learn from their kids field hockey teams, the Dutch team might be the next world champion. And our projects might actually succeed.

Evolving agile

Posted on by
1

Without any doubt agile is the biggest evolution in software development approaches since the introduction of waterfall back in the early seventies. And yes. Agile is an evolution rather than a revolution. The best practices and techniques in agile didn’t just pop-up. Rather they emerged from years of hard-working, real-life experience in succeeding and failing in projects.

So working in short iterations, in multi-disciplinary teams, prioritizing our work items regularly, and testing and delivering early and frequently using simplified communication, as we could capture agile in a single sentence, are improvements we’ve all introduced in our software development projects over the past forty years. Agile, and all of it flavors, such as Extreme Programming, Scrum, Smart or Kanban, have merely evolved from teams trying to do a little better every day. And have succeeded in doing that.

In the second decade of this century, due to the overall success of agile approaches, the majority of organizations executing projects will move towards agile. Either quickly or slowly. And for a variety of reasons. To raise quality. To increase predictability. To execute on-time, on-budget. To minimize time-to-market. Or simply because Gartner says so.

But with the success of agile come new challenges. Agile projects require agile coaches. Whether certified as Scrum Master, Lean Champion, or Pokémon Trainer, there is a lack of sufficiently experienced agile coaches. As a result an increasing number of projects is guided by ill-experienced coaches, often leading to a dogmatic and rigor application of agile. More over large organizations will feel the need to standardize, industrialize or institutionalize their agile efforts, resulting in ill-digestible, comprehensive agile manuals.

Although adaption and creativity are fundamental to agile, these growing pains will slow down the enormous progress we are making in the field of software development approaches. Agile is meant to evolve. Always. Continuously. Improving and professionalizing our software development is not a frog-leap process, proceeding with one giant leap every fifteen years. It is an fluid, never-ending process of many, many little steps taken on a daily basis. We learn from what we do. Yesterday, today, tomorrow, next year.

This post was written as a contribution to the upcoming book “Shaping Apps Germany”, published by Capgemini, Germany.

A short notice about object relational mapping framework generated queries…

Posted on by
Reply

I guess object relational mapping is an accepted paradigm for exchanging data between an object oriented domain layer and underlying databases. For most applications object relational mapping is more than sufficient. And if not, perhaps command query responsibility segregation might contribute well to your solution.

Being a more than frequent user, this very short blog post is not meant to question either of these popular paradigms. However, I would like to make it clear that applying object relational mapping might not always lead to optimal solutions, especially from a database perspective. Most object relational mapping framework generate the underlying queries to the database, based on the domain layer and the associations between the domain objects in this layer. The quality of these generated queries is strongly dependent on the quality of the domain model and layer. If the domain model is complex, so will the generated queries be. Rubbish in is rubbish out.

image

So it is noteworthy how the framework you’re using maps associations and properties to SQL statements. Some frameworks may choose remarkable construct for this mapping resulting in hard and unreadable queries, or queries that aren’t very much optimized for the underlying data model. So this short blog post is just to make you notice.

The problem actually comes from the enormous amount of features a full-grown object relational mapping framework needs to implement. Basically, everything and the kitchen sink. Driven by the good but blind ambition to serve as many developers as they possibly can, in any case more than all other competitors, the framework developers implement as many features as the code in the framework can handle. And sometimes this feature bloating may lead to peculiar results, where the framework might still function, but the original goals of providing a lightweight, straightforward, easy-to-use framework to solve most common mapping problems have long been abandoned.

For developers using such frameworks I guess the most decent piece of advice I can give is: don’t go into the dark corners of domain modeling, as the solutions resulting may be hard to maintain and to extend. Use middle-of-the-road constructs, and prefer simpler, more generic out-of-the-box solutions to more specific and elaborate domain models.

I’ll leave with an example of a query which was generated by a frequently used object relational mapping framework in the .Net space. I’m quite sure the database will have a hard time executing this particular query.

And yes, the following is indeed a single select query. Go figure.

SELECT

[Extent1].[ID] AS [ID],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN ’2X’ WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1) AND([UnionAll2].[C6] IS NOT NULL)))) THEN ’2X0X’ WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THEN ’2X0X0X’ WHEN(([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN’2X1X’ ELSE ’2X1X0X’ END AS [C1],

[Extent1].[MAPReportId] AS [MAPReportId],

[Extent1].[PartnerNumber] AS [PartnerNumber],

[Extent1].[CapturedVia] AS [CapturedVia],

[Extent1].[Currency] AS [Currency],

[Extent1].[DataAsOf] AS [DataAsOf],

[Extent1].[DateApproved] AS [DateApproved],

[Extent1].[DateCreated] AS [DateCreated],

[Extent1].[DateProcessed] AS [DateProcessed],

[Extent1].[DateReturned] AS [DateReturned],

[Extent1].[DateSubmittedToRo] AS [DateSubmittedToRo],

[Extent1].[PeriodCovered] AS [PeriodCovered],

[Extent1].[ProcessGeneralComments] AS [ProcessGeneralComments],

[Extent1].[ReasonReturned] AS [ReasonReturned],

[Extent1].[StatusID] AS [StatusID],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[AverageLoanSize] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL))THEN [UnionAll1].[AverageLoanSize] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C2],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[AveragePortfolioOutstanding] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6]IS NOT NULL)) THEN [UnionAll1].[AveragePortfolioOutstanding] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT(([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C3],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[BoYPortfolioOutstanding] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] ISNOT NULL)) THEN [UnionAll1].[BoYPortfolioOutstanding] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT(([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C4],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[DepositsAmount] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL))THEN [UnionAll1].[DepositsAmount] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C5],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS int) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1) AND([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[EoYNrBorrowers] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THEN[UnionAll1].[EoYNrBorrowers] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS int) END AS [C6],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[EoYPortfolioOutstanding] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] ISNOT NULL)) THEN [UnionAll1].[EoYPortfolioOutstanding] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT(([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C7],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS varchar(1)) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] =1) AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[MFIPortfolioSize] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOTNULL)) THEN [UnionAll1].[MFIPortfolioSize] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] =1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS varchar(1)) END AS [C8],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS int) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1) AND([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[NrLoans] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THEN[UnionAll1].[NrLoans] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS int) END AS [C9],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[InvestmentOutstanding] WHEN (([UnionAll2].[C6] = 1) AND([UnionAll2].[C6] IS NOT NULL)) THEN [UnionAll1].[InvestmentOutstanding] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C10],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[LoanOutstanding] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] ISNOT NULL)) THEN [UnionAll1].[LoanOutstanding] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT(([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C11],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN [UnionAll1].[OutstandingExposure] WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOTNULL)) THEN [UnionAll1].[OutstandingExposure] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT(([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C12],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS varchar(1)) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] =1) AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS varchar(1)) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL))THEN [UnionAll2].[C1] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS varchar(1)) END AS [C13],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THEN[UnionAll2].[C2] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6]IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C14],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THEN[UnionAll2].[C3] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6]IS NOT NULL)))) THEN CAST(NULL AS float) END AS [C15],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS varchar(1)) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] =1) AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS varchar(1)) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL))THEN [UnionAll2].[C4] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN CAST(NULL AS varchar(1)) END AS [C16],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS bit) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1) AND([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS bit) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THEN[UnionAll2].[C5] WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND ([UnionAll1].[C6]IS NOT NULL)))) THEN CAST(NULL AS bit) END AS [C17],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THENCAST(NULL AS float) WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN [UnionAll2].[Exposure] ELSE [UnionAll2].[Exposure] END AS [C18],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THENCAST(NULL AS float) WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN [UnionAll2].[InvestmentOutstanding] ELSE [UnionAll2].[InvestmentOutstanding]END AS [C19],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT (([UnionAll2].[C6] = 1)AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS float) WHEN (([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)) THENCAST(NULL AS float) WHEN (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] IS NOT NULL) AND ( NOT (([UnionAll1].[C6] = 1) AND([UnionAll1].[C6] IS NOT NULL)))) THEN [UnionAll2].[LoanOutstanding] ELSE [UnionAll2].[LoanOutstanding] END AS [C20],

CASE WHEN (( NOT (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL))) AND ( NOT (([UnionAll2].[C7] = 1) AND ([UnionAll2].[C7] ISNOT NULL)))) THEN CAST(NULL AS decimal(18,2)) WHEN (([UnionAll1].[C5] = 1) AND ([UnionAll1].[C5] IS NOT NULL) AND ( NOT(([UnionAll2].[C6] = 1) AND ([UnionAll2].[C6] IS NOT NULL)))) THEN CAST(NULL AS decimal(18,2)) WHEN (([UnionAll2].[C6] = 1) AND([UnionAll2].[C6] IS NOT NULL))

Het institutionaliseren van agile

Posted on by
3

Er is een anti-patroon op het gebied van agile dat me nauw aan het hart gaat. En dat is de institutionalisering van agile.

In de afgelopen vijftien jaar heb ik met veel plezier en inzet organisaties en projecten gecoacht op weg om agile worden. In die vijftien jaar heb ik ongelooflijk veel geleerd, over software ontwikkeling, over programmeren, over processen, over het doen van projecten maar misschien vooral over de mensen in die projecten, en hoe deze mensen samenwerken. En het moet gezegd worden, ieder mens is uniek, iedere samenwerking is uniek, en vooral daardoor, los van alle technieken en technologie, is ieder project anders.

Handboeken agile

Nu zijn we op een punt in de tijd beland dat agile populairder is dan ooit, en waarschijnlijk zelfs populairder is dan het ooit in de toekomst nog gaat worden. We zijn op het punt dat alle grote organisaties hun software ontwikkeling gaan veragiliseren. Dit is het punt in de tijd waarop meer en meer projecten agile worden uitgevoerd. En dit is daarom ook het punt in de tijd dat grote organisaties gaan vastleggen hoe agile projecten dienen te worden uitgevoerd.


Handboek agile in zes delen

Er zullen steeds dikkere en gedetailleerde handboeken verschijnen met voorschriften over hoe lang een stand-up meeting mag zijn, welke vragen daarin moeten worden behandeld, hoe groot een team mag zijn, met welke ontwikkelomgevingen de ontwikkelaars moeten werken, welke testtechnieken mogen worden gebruikt, templates voor het vastleggen van user stories, smart use cases, evaluaties, en wellicht zullen er organisaties zijn die zo ver gaan dat ze gaan voorschrijven dat user stories op langwerpige gele post-its op het taskboard dienen te hangen en individuele taken op vierkante groene.

De geest terug in de fles

Als ik één tip mag geven? Zodra deze verschijnselen zich voordoen in een organisaties is agile ten dode opgeschreven. Agile projecten varen wel bij de juiste hoeveelheid vrijheidsgraden, mensen en samenwerking varen wel bij de juiste hoeveelheid vrijheid. Software ontwikkeling is een creatief proces, en agile werkwijzen zijn geëent op het zichzelf voortdurend verbeteren. Zodra organisaties agile gaan institutionaliseren, wordt de creativiteit langzaam maar heel zeker uit de projecten getrokken. Het zelflerend vermogen van agile projecten aan banden gelegd. De geest is weer terug in de fles, en de stop kan erop.

Death by Dogma versus Agile Assembly

Posted on by
4

On November 3, 2011 I presented the keynote of the Agile Open Holland Conference in Dieren. During this challenging talk I discussed the current state of affairs in agile organizations and projects and the effects of the recent strong rise in popularity of agile approaches. Let’s put it mildly: there’s a lot of work to be done.

Death by dogma

Almost all organizations, large and small, are turning towards agile to escape failing traditional software development projects. Due to this strong increase in popularity of agile approaches and techniques, many newcomers will enter the field of agile coaching. Of course without the very necessary real-life experience but proudly waving their Certified Professional Scrum Master Sensei Trainer Certificate proving they at least had two days of training.


Going through the hardship of two whole intense days of training becoming a Certified Agile Jedi Knight is worthwhile!

In my opinion, as a result many organizations and projects in the next couple of years will be coached why well-willing consultants who have barely made it through boot camp, and in the famous Shu-Ha-Ri learning model haven’t yet made it beyond copying their teacher. This will lead to very dogmatic applications of the more popular agile approaches, mostly Scrum, especially when the so-called leaders in the field themselves turn to dogma. This dogmatic thinking will block the use of more mature techniques and technology in agile projects, even when these would really improve projects, or would prevent agile projects from failing. “No, you can not do modeling in Scrum” and “Burn-down charts are mandatory” are two such simple real-life example statements that I’ve witnessed some certified agile Jedi Knight make. Due to this lack of experience and the growing dogmatism in the agile beliefs, more and more agile projects will fail. Death by dogma.

During my keynote I discussed many examples of dogmatic Scrum implementations and the drawbacks from being dogmagile, building the story up from my previous posts Scrumdamentalists and Crusaders and Flower-Power Agile Fluffiness.

But maybe even more important during the keynote I also show that there is no such thing as one-size-fits-all agile. Different organizations and different projects require different agile approaches. Sometimes lightweight agile, for instance implemented using Scrum, user stories, simple planning, simple estimation, and one co-located team using post-its on a wall is just fine. But in many projects the way of working used should rather be built up from slightly more enterprise ready approaches, for example using Smart, smart use cases, standardized estimation, multiple distributed teams and on-line dashboards.

What is agile anyway?

Implementing agile in your projects starts with establishing what it means to be in an agile project. As I demonstrate in the keynote, I consider short iterations, collaborative teams, a small unit of work, continuous planning, delivering early and often, and simplifying communication to be crucial to considering a project working in an agile way.

From there you can pick and choose from a wide variety of approaches, techniques and technology. Most of them stemming from the agile era, but some of them can also be related to older (or more mature) era’s. Concluding you might say that to be successful in implementing agile in your organization, you will need to assemble your agile approach from everything that will help you implement these six agile bare necessities. Anyway, enjoy!

Death by Dogma versus Agile Assembly

Flower-Power Agile Fluffiness

Posted on by
27

To all the dear people in the agile community and to the faint-hearted: this will not be an easy blog post. There was a time when being a software developer was a decent craft, requiring decent craftsmanship and yes also a lot of creativity, some communication, some collaboration. Still it was a decent craft. The waterfall-ish methodologies we used weren’t extremely optimal, but at least software development was a craft. Similar to a carpenter who uses his tools to craft new furniture, or a industrial designer using his tools to come up with a new model Toyota – I know this is not the best example, but at least I now have the attention of the kind folks in the lean community. And then came agile.

Now believe me, I don’t have anything against agile. I’ve been promoting agile and iterative approaches to software development since the mid-nineties, and haven’t done traditional projects ever since. Agile used to be about engineering. We were improving ourselves by using better techniques, continuous integration or continuous deployment, writing unit test, pair programming, writing smart use cases or user stories, using a bug tracker, burn-down charts and even post-its on the wall. So far, it’s still all in a days work. There was a time that as an analyst, a developer, or a tester you could be proud of being in an agile project.

But these days if I look at what’s going on at agile conferences, on twitter, in blog posts, literature and discussions on agile, Scrum, Lean, Kanban and whatever new flavors of the month are passing by, I get the feeling I’m no longer talking about craftsmanship but rather ending up in Disneyland or in San Francisco in the late sixties. I’ve got a feeling were not in Kansas anymore.

image
Agile coach at work.

Agile community anti-patterns

Certainly it’s a good thing everybody can join the agile community. But I witness a lot of repetitive behavior I strongly discourage. Let’s name this repetitive behavior agile community anti-patterns – not to confuse with agile anti-patterns. The latter merely describe failures in agile projects, and yes these do occur, while the former describe community failures. Let me sum some up for you – while on the fly breaking my first anti-pattern:

  • Metaphorizing
  • Zenify
  • Kindergarten Agile
  • Open Door Wisdom
  • Scrumdamentalism

Allow me to elaborate a bit on these agile community anti-patterns.

Metaphorizing

Although I’m not sure metaphorizing is a even good English word, I’m quite sure you get the meaning of it. Everything anybody comes up with these days about agile – or about what people think is agile – is immediately turned into a metaphor or is given a silly name.

Can we please stop talking about the Gemba Walk when we mean that it’s a good thing our manager stops by every now and then? This shouldn’t even have a name.

image
Japanese manager stopping by.

What does it mean when an agile specialist states that “you should verify the five why’s with the reverse loop”? And what about Feature Injection? According to a recent tweet “feature Injection is more about using examples to discover the relationships you need and missed or got wrong.” Call me old-fashioned but I totally miss what this is about.

Zenify

Yes, I know lean manufacturing started in Japan at Toyota. So there is a link between agile and Japan. But is that an argument to zenify software development?

image
Our new Feng Shui office space.

Why do we need to explain roles in a software development project as samurai, sensei or roshi. I thought product owner and agile coach were already abstract enough. What about re-arranging our office in a Feng Shui manner? Also the word kaizen seems to become very popular. Quoting a recent tweet: “Just write down small things on small papers. It’s your kaizen.” Although I’m all for small things what does this mean and why do I need to introduce this in my project?

Kindergarten Agile

Not sure about the average level of maturity of people in agile projects around the world, but in the projects I’ve been in the last decade or so, people where pretty mature. So why is it groups of sensible people at unconferences are discussing the Happiness Index of projects? To me this sounds much more like a weekly column in a women’s magazine than a solid engineering practice in a software development project.

And I for one certainly don’t want to have to pass a baton if the flow in my stand-up meeting or scrum isn’t achieved automagically. Still this was seriously recommended by one of the authorities in the agile community during a recent presentation at a conference.

Some tweets to further illustrate my point? If someone says “Add Ready for Celebration before the Done column on your wall board” should I start decorating the office? It makes you wonder how often his projects get things done. Even worse is “Make sure you don’t miss the agile elephant versus the waterfall elephant in the lobby.” which was tweeted from a recent agile conference. Where was this conference held? At the Toys-R-Us?

image
Participants at a recent agile conference strolling down the exhibition hall.

Open Door Wisdom

Often I see quotes coming from the agile community that are no more than open doors, and have been open doors in projects for decades and perhaps centuries, but that are treated by others in the community as sources of new and ultimate wisdom.

Recently a speaker at an agile conference claimed that “if your retrospectives don’t add value to your project, you should change your retrospectives.” Duh. The speaker got a loud applause from the audience, he is now considered an absolute guru, and his quote got tweeted and re-tweeted all over the world. This is not even an open door, it’s an open gate.

Scrumdamentalism

Now I’ve blogged about Scrumdamentalism before, but with the newer generations of agile converts, some communities are getting more and more populated by religious zealots who will treat their newly gained faith with deep fundamentalism. Any best practice from their own belief is treated as mandatory, while followers from other beliefs are often considered heretics. A recent blog post states that: “A technical project manager can be a good product owner if he sticks to managing the product backlog and abiding by the rules of Scrum.” I wasn’t aware that Scrum even had rules. You learn something new everyday.

And if Scrumdamentalism alone isn’t bad enough already, it is even enforced by the so-called leaders themselves, proven by the following horrible quote “the team needs to listen to god talk and follow the commandments” from one of the Great Leaders in this particular community. Dear agilists there is is no one-true-belief. There’s value in all of them. And also can we please abolish the function title Agile (or Scrum or Kanban or Lean) Evangelist. Moreover, people calling themselves Agile Sensei should be banned from conferences and projects if you ask me.

Flower-Power Agile Fluffiness

Please people can we stop adding all this new age Flower-Power fluffiness to agile. In my opinion the agile community with all it’s great ideals and best practices is slowly degrading into a worldwide Luna park. My guess is I that it won’t be long before someone somewhere will suggest to add a psychotherapist to every software development project. “How do you feel about not being able to get your user story to the Ready for Celebration column?” Or plan a clown’s visit during retrospectives to increase the Happiness Index.

image
Agile retrospective with product owners present.

We are slowly becoming the laughing stock of the engineering world. I long for the time that we re-introduce engineering in our trade, and all go back to work again.

Scrumdamentalists and crusaders

Posted on by
7

After having promoted agile and iterative approaches to software development projects for over a decade, I finally find that, like Bob Dylan says, the times they are a-changing. And for the better. Many small and large organizations and enterprises are now turning towards agile approaches, often to compensate for years and years of failing projects. You might suggest that all’s well that ends well . But…

With the growing success of agile approaches new patterns and anti/patterns arise. Implementing agile well, although promoted as being easy by many, isn’t that easy. It’s actually quite hard to get it right. Implementing agile well is a learning process, just like learning to ride a bicycle well, or learning how to master a programming language. This is where coaching on the job can and should play an important role.

Pokemon Trainers and Jedi Knights

But good agile coaches are scarce these days. So many companies jump into this growing gap and send of there consultants to far away agile training courses. Inexperienced or at most with little experience these suddenly acclaimed Scrum Masters, Lean Certified Project Managers, Pokémon Trainers and Jedi Knights are now pushed into the marketplace.

Let me predict you that this explosion of these new gurus will lead to massive agile project failure. Allow me to explain. As with most religions, people just entering the new belief tend to be far more fundamentalistic and dogmatic about their new faith than people who have lived in the same religion for years. Newbies will apply the religion’s commandments far more literally than they are meant – as the elders know. And moreover, these newbies will see there new religion as the only true source of knowledge, denying the value in other religions.

In a sense you might say we’re in the Agile Middle Ages. The new agile fundamentalists are like crusaders, full of enthusiasm, heavily armed, not very adapted or open to the new world they travel too, but with an urge to strike down all non-believers.

image
Agile fundamentalist in the field

Scrumdamentalism illustrated

This fundamentalism is best witnessed in the Scrum community. Personally, I like Scrum a lot, but too often I see Scrum certified coaches making remarks about what is and what isn’t Scrum, and even worse: what is and what isn’t agile. Let me illustrate my statement with some real-life examples.

In many projects, especially the more enterprise projects, I prefer modeling smart use cases and use these as unit of work, estimation, development and testing way over the more unstructured user stories. At quite a few occasions Scrumdamentalists have come up to me and claim that you must use user stories, otherwise you’re not doing Scrum, but instead you are doing waterfall. Modeling doesn’t seem to be allowed  anyway in a Scrum project, if I believe my Scrumdamentalists.  Now I haven’t read the little Red Book of Scrum, but I’m pretty sure Scrum doesn’t really push user stories as being mandatory, nor forbids modeling.

Another great example followed a picture I tweeted of my current project’s dashboard during a week when our tester was on holiday. Clearly the list of work items to test was larger than the other columns. My picture led to a remarkable comment from a certified and even experienced Scrum Master that all team members should automatically take over each others work when someone is offline. And if we didn’t do that we were not doing agile, but were doing waterfall instead.

Yes I do consider that taking over each others work is good practice, but to a certain extent. I don’t know about your project, but in my project testing is serious business, with serious techniques, that requires serious expertise. Testers do totally different work than analysts or developers. I don’t see any of my C# developers creating process cycle tests or writing functional test cases. Or even worse, the other way around. Would you seriously consider a tester to learn how to write C# code, just because one of the developers spends a week on the beach? So I guess I’m in a waterfall project.

IMAG0024
A non-proper agile dashboard

And if you think this was the low point of my experiences, another Scrumdamentalist overlooked the picture I posted and noticed that my project has different and more stages a work item goes through than the task board he considered obligatory. We had stages such as developer testing, testing, accepting and approving, while he said that you only have to-do, working and done on a proper task board.

And dear people, is it really necessary to call an iteration a sprint, and a stand-up meeting a scrum to make my project successful?

Process fits project

I strongly believe that this agile fundamentalism and dogmatic thinking is going to stop progress and productivity. It ignores on of the basic principles that makes agile such a strong proposition – namely to improve on your process and techniques continuously to make the process fit your project, and not the other way around.

Dear people in the agile communities, please don’t try to become holier than the pope. Being agile means not trying to be dogmatic. We are not looking for the holy grail. There is no one true agile religion I’m afraid, there’s value in all of them. As the agile manifesto clearly states: we are uncovering better ways of developing software by doing it. So go out and explore.

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.

November 12, 2010 – Microsoft TechEd Europe. How smart use cases can drive web development

Posted on by
Reply

[Session ARC205 at Microsoft TechEd Europe 2010 in Berlin]

Use cases have been around for many years describing the requirements of software development projects. From a developer’s point of view, use cases are often seen as too abstract and too complex to develop code from. Until now, that is.

IMAGE_004[5]

During this interactive talk, speaker Sander Hoogendoorn will demonstrate how to model, generate and build smart use cases.

image[8]_thumb[2]

This great technique allows you to model use cases at a much more pragmatic, low-granular level, enabling them to be implemented simply and directly into applications such as ASP.NET or Silverlight. Using many real-life code examples, the speaker will introduce both the positive impact that smart use cases have on your layered software architecture, as well as the design patterns required to implement them.

20101007 how smart use cases drive web development