My Collection of Coderetreat Session Practices – Part 2

If you are looking for some new ideas for your next coderetreat your are in the right place. This posting describes a second set of 13 session practices for coderetreat. The first set can be found here. Most of these practices are well known in the community or have been already used my own coderetreat practice, but some just came in my mind when writing this post. If you use one or another of the session practices below, please provide a short comment about your experience with the particular practice you used.

#21 Grid with fixed size

Per default, the GOL grid has infinite size and so, has no border. In this session you have to respect a grid with fixed size, e.g. 3×3 or 4×4. Cells on the border don’t have eight neighbors so you have to find a solution how to handle calculation of neightbors for these cells.

#22 Grid without border

This is the default GOL grid nature. But, in case you are accustomed to fixed size grid it’s probably an interesting alternation.

#23 Choose any three

There are four properties of Simple Design:

  • All tests are green
  • No code duplication
  • Meaningful names
  • As little code as possible

Choose any three from this list and examine after this session, whether something went wrong with your code because of the missing fourth property of Simple Design.

#24 Focus on 3-A

Unit tests should satisfy the 3-A-pattern: Arrange-Act-Assert

Each method should group these functional sections, separated by blank lines:

  1. Arrange all necessary preconditions and inputs.
  2. Act on the object or method under test.
  3. Assert that the expected results have occurred.

From my experience, this structure isn’t practiced often when writing unit tests. So,  it’s probably a good session practice for your next Coderetreat. Assemble-Activate-Assert is a pattern that is nearly similar.

#25 Von Neumann Neighborhood

Normally, the 8-cell-Moore Neighborhood is used to calculate number of living neighbors in GOL. You could alternate this strategy by using the 4-cell-Von Neumann Neighborhood where the cells diagonal neighbors don’t count.

Moore and Von Neumann neighborhood

#26 Integration tests only

In TDD, the focus is on unit tests that have the right granularity to help a pair of developers to test the method that is developed right now and to ensure that all the other methods still work as expected. In this session only a really coarse grained unit test is allowed that checks the right result when calculating the next generation of GOL. You will realize that this test goes green the first time when your implementation is nearly finished. I case there is a bug in your code the test will probably not help you to identify the source of the bug.

#27 Truck factor session

In the middle of the session one member of the pair isn’t longer available and must be replaced by a peer from another pair – which happens to each pair. In this session you practice how to introduce a new peer to a task in progress and how to become acquainted into a new job.

#28 TDD randori session

A TDD randori is a format where only one pair is working on the given problem (e.g. GOL). The IDE of this pair is shown to all the other participants of the retreat by using a beamer. After three minutes or after finishing a (test) method the navigator or pilot leaves the pair and one member of the audience takes the free seat. After three minutes or the next (test) method the last remaining member of the pair that started the session leaves his seat and another member from the audience takes his seat. This procedure proceeds every three minutes or after finishing the next (test) method ’til the 45 minutes are over.

#29 No shortcuts

Most developers are accustomed to use dozens of shortcuts in their IDE within one minute of coding. In this sessions using shortcuts is forbidden. Developers often get into trouble the moment they have to click on menu entries to run their IDE. Nevertheless, this session is a lot of fun … after the first wave of swearing is over.

#30 No tests

Unit tests is what makes responding to change easy. In this session we skip writing tests alltogether. By doing so, we have no idea whether our solves the problem or not. After this session you are happy that you are accustomed to write unit tests in your daily programmer’s life. This session can be easily combined with session #31.

#31 Tests as an afterthought

In this session you need the code from a prior session (which you didn’t delete). In case there are unit tests, please, delete these tests. Focus of this session is to try to understand what the pair that produced that code without tests intended and to proof your assumptions by writing the right tests. After you produced an adequate test quality, feel free to refactor the code in question.

#32 Do something

Focus of this practice is to use meaningless names in classes, methods and attributes, in code and tests as well. Probably you have experienced a lote of doSomething() methods and MyClass classes in your programming carreer. Goal of this session is to understand the value of meaningful names.

#33 Waterfall-driven development

When practicing TDD you write or change one single unit test and then write or rewrite one single public method (and probably some code that has to exist behind the scene). Try to write all the tests you think you will need to solve the GOL (or your particular goal) beforehand. Then, try to produce the GOL code step-by-step or method-by-method and see, whether your assumptions about testing have been right. They are probably not complete right and you learn once again why focussing on tests you need right now is an good idea instead of writing tests the waterfall-driven way.

#3 – Pragmatic Enterprise Architecture – Decentralization, Architecture owner …

This is the last part of my Pragmatic EA series. In the first part I discussed value before strategy in the second part I wrote about minimal artefacts and inconsistencies in business domain pureness. This last posting addresses the following aspects:

  • Decentralization
  • Architecture owner role
  • Enterprise architects and their role in real-life projects
  • Platform strategy

Additionally I discuss whether we need a new kind of enterprise architecture frameworks or not.

Aspect 6: Decentralization

Each IT landscape has areas the change at different speed and intensity. This results in different non-functional requirements in connection with flexibility, extensibility and, maintainability of the IT systems that are involved.

Therefore, EAM has to define the scope of these areas. Rapid changes in an IT system in one area must not lead to changes in systems in other areas in case there is no connection between the IT systems in question. In case there are dependencies because of similar change frequency between IT systems of different areas, the profile of these areas is probably wrong.

Aspect 7: Architecture Owner

In Scrum there is the role of the product owner (PO). The PO decides for a product which functionality and which features currently have the highest business value or address the highest risk and, should be implemented or changed by the development team next. The development team makes all functional and technical decisions. In case effort arises from design decisions it is made visible to the product owner. This enables the product owner to prioritize functionality and features by having effort in mind.

But, there are also design decisions that have comprehensive effects not only to the product itself but also to other IT systems or the overall IT landscape. This is no decision a single development team should make. From my point of view there should be an Architecture Owner that is responsible for all the design decisions that are not in scope of a single product or software system. The selection of the technological platform for the whole organization is an example for the responsibility of the Architecture Owner. So, the Architecture Owner has a similar role as the Product Owner. The Product Owner is responsible for the product; the Architecture Owner is responsible for architecture and design of the IT landscape of the organization.

There has to be someone who has responsibility for all architecture and design decitions – Architecture Owner. Image source sokaeiko /

The Architecture Owner is a stakeholder for all the products and IT systems in the organization. In case there is a design task to do or a design issue to solve for a particular system, the Product Owner of that system has to be addressed. On the other hand, all products and IT systems have a stake towards enterprise architecture. They all have to address this stake towards the Architecture Owner.

In large organizations with hundreds or thousands of IT systems Architecture Owner is not an one-man-show. There has to be a team of Architecture Owners. The members of this team are responsible for a particular domain inside the IT landscape. But, there also has to be an Architecture Owner who has the overall responsibility for the architecture of the IT landscape and the Architecture Owner team should report to that person.

Aspect 8: Enterprise architects and their role in real-life projects

In an Agile world enterprise architects are still important. But, similar to the role of EAM the role of an enterprise architect changes in an agile world too. From my point of view, enterprise architects should work partially in a real-world project to help to reduce the disconnect between EAM and teams or between EAM and projects. This way, enterprise architects get a chance to address EAM problems in these projects and, the other way around, they get insight into the real-world issues of teams and projects that could be solved with support from EAM.

Aspect 9: Platform strategy

In the ideal EAM world there are no IT systems or products with exotic technologies. The moment an organization decides for a platform strategy and enforces its application, some layers of the IT landscape architecture like application or infrastructure architecture lose its complexity. Each team and each IT system has to deal with this basic condition. But, be careful. I suggest not deciding for one single platform approach but for a set (two or three) platforms: You know, a hammer isn’t the best tool for each problem.

Does this mean we need a new generation of EA frameworks to address the new role of EAM in an agile world?

Currently, there are a lot established EA frameworks. At you can find about 300 frameworks that somehow support EAM issues. From my point of view, all of these are suitable for Pragmatic EAM and so, no, we don’t need a new generation of EA frameworks. There is no reason to cast away existing knowledge and experience just to start with an EAM with focus on flexibility and pragmatism anew.

It’s more productive to put our existing EA frameworks into a slimming diet: Everything that doesn’t generate visible value is obviously waste and can be omitted. Artefacts that have a visible value should be minimized to the parts that create that value. This will also help to save effort when creating and maintaining these artefacts.

Knowledge and experience of agile and lean values and principles will help us to create value by using the current EA methodologies and will lead towards an EA that supports us when responding to our fast changing business world. In the agile world development processes are changed evolutionary in a way that helps to support creation and maintenance of a product very well. From my point of view, a similar process of maturing makes sense for our EA frameworks as well.

My Collection of Coderetreat Session Practices – Part 1

If you are looking for some new ideas for your next coderetreat your are in the right place. This posting describes the first 20 of a list of about 40 session practices for coderetreat. Most of these session practices are well known in the community or are taken from my own coderetreat practice. There is no specific order inside this list.


#1 Muted session

There is no verbal communication between the peers of the pair. Goal of the practice is to show how important direct communication between the peers is.

#2 100% Test Coverage

The pairs try to achieve test coverage of 100% with their unit tests. Goal of the practice is to show how expensive a high percentage of test coverage can be. You may need a framework in your IDE that allows you to measure test coverage.

#3 SOLID Session

SOLID is an acronym for Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion. These are the five basis principles of object-oriented programming and design. Goal of this practice is bring back to mind that this is the way object oriented programming always should be done. This practice should work with functional languages as well.

#4 Evil (muted) Coder

One peer of the pair writes a unit test and the other peer implements functionality for this test that barely passes the test. Then the first peer tries to force the other peer to write better code by improving his unit test. Goal of this practice to make clear that a test has value in case it can fail.

#5 Fast Alternation

Both peers switch roles (navigator, pilot) after 60, 45, or 30 seconds. Since most pairs change roles seldom in a TDD session this practice helps to show the participants how they fare when switching roles more often.

#6 Don’t Delete

Don’t delete the code of your previous session. Another pair will sit on your computer and tries to understand what your code does und will refactor it. This session helps to understand which problem precise naming and single responsibility help to solve.

#7 No Return Values

No method should have a return value. To be able to check the behaviour of the code under test the pairs have to use the inner state of their classes. This session practice should help to understand that testing by using the inner state of a class is completely wrong. Additionally, unit tests that don’t handle return values of methods look somehow wrong, too.

According to the programming language in use, some methods must have a return value to be able to run the program or the tests.

Some pairs use input/output parameters instead of return values, which is not in the sense of this session practice.

#8 No Parameters

No method should have input or output parameters. It is valid to use checkSomething or isSomething methods that return a value that can be tested. This session practice should help to understand that testing by using return values only makes tests more complex and harder to understand.

According to the programming language in use, some methods must have parameters to be able to run the program or the tests.

#9 No Return Values and no Parameters

The pairs should use no parameters and return values when coding in this session. Most pairs will solve this issue by using inner states of classes and testing against them. This programming style is an anti-pattern and will help participants to understand that working with the inner state of classes is a bad idea generally.

#10 At most 5 Lines of Code per Method

In this session maximum size of a method is five lines of code. This leads to really fine-grained methods and fine-grained tests too. The code becomes more complex. This session helps to find the right level of granularity for methods and theirs tests as well. Alternatively you can set the maximum to three lines of code.

#11 Dictator

The moderator of the coderetreat will instruct each pair what to code and how to code. What looks like an anti-pattern will help the participants to understand why it’s important that the one who does the coding also should do design.

#12 No Loops (for, while)

During this session no loops are allowed. This typically leads to new solutions in connection with iterating over neighbour cells for Conway’s Game of Life playing field. This session normally leads to mode lines of code.

#13 No Conditions (if, ?, switch)

In this session no pure if-conditions in the code are allowed. This makes it hard to make the code readable. Sometimes pairs struggle to solve the problem generally or the code is really hard to read.

#14 No Else-Conditions

No Else-Conditions are allowed in this session. If the participants want to express an else condition they have to use another if-statement or something similar. The code becomes more complex and is harder to read. This session helps to understand to use if/else careful and in the right context.

#15 No Objects

In this session no object types are allowed: Integer attributes should be expressed using int, Boolean should become bool etc. Precondition it that the programming language in use supports primitives at all. This is not the case with c#.

#16 No Primitives

In this session object types only are allowed: Int is expressed using Integer; bool should become Boolean etc. Precondition is that the programming language in use supports primitives at all. If this is not the case like in c# the participants could create richer object types like coordinates with state etc.

#17 Verb instead of Noun

Use of nouns is prohibited during this session of all attributes, methods and class names. Code becomes less readable. Since we are accustomed to use nouns we become aware that there is a high value in using nouns.

#18 No Mouse

No mouse is allowed during this session. Participants who are accustomed to use the mouse all the time will probably learn new shortcuts for the development environment and can become much more efficient by using shortcuts consequently.

#19 Unknown Machine

The pair is having its session on someone else machine probably with an unknown development environment, unknown keyboard shortcuts etc. This type of session helps the participants to get accustomed to unexpected change.

#20 Cold Water

This is the starting session of most coderetreats. The pairs are confronted with the problem to solve for the first time and have to get accustomed with the environment, the coding partner and, probably with TDD too.

The second part of my session practice list is not yet written down.

#2 – Pragmatic Enterprise Architecture – Minimal artefacts and current information

This is the second part of my Pragmatic Enterprise Architecture Series. In the first posting I wrote about business value of EAM and business first approach when prioritizing EA related work. In this posting I discuss the next three Pragmatic EA ideas:

  • minimal artefacts
  • actuality of information
  • temprorary inconsistencies in business domain pureness

Aspect 3: Minimal artefacts

One reason for the missing binding between EAM and the agile world is the heavy weight of EA frameworks. From my point of view most EA frameworks are based on complex, extensive artefacts and rules. Keeping a costly artefact current takes time and effort.

An agile team probably needs no more than an overview of the existing business domains and the current service catalogue. A comprehensive collection of all information objects has a much lower meaning. This is because a service catalogue normally contains enough information to extract all information objects needed for my purpose. If the teams that are involved – service partner and the system of the agile team – need to exchange additional information they can do this directly without EAM involvement. EAM gets unburdened.

Most things are much simpler than they look like. Just have to make simplicity visible. Chess automation scetch. Picture source:

Being agile is supported by simplicity. Simpler EA frameworks and processes tend to support simpler and more flexible solutions. This is exactly what an agile team needs and probably everyone else too. But, before we start to invent umpteen new EA frameworks it’s probably a good idea to shakeout the EA frameworks we already know and use. From my point of view most EAM frameworks can become much easier when we change the framework focus towards benefit instead of rules.

Aspect 4: Actuality of information

Actuality of information in EAM has been problematic in the past. I don’t remember how often I found out that current information for instance of a common interface have been out-dated for at least a couple of weeks and some important changes have been missed by EAM. One reason for this gap in actuality was that EAM simply hasn’t had enough time or capacity to keep all information current. Another reason as of course because of the teams that missed to deliver information about changes to EAM team.

Just imagine you could dispose a change in the service catalogue is automatically added to the catalogue the moment the change goes in production. Your organization would win a lot. The central maintained plan that looks in the remote future and that has to be changed potentially each day can be skipped completely.

Aspect 5: Temporal inconsistencies in business domain pureness

Preparation of a new or changed service in the right section of a domain landscape is even in an agile world not possible within four weeks all the time. As a result business is affected and sales is at stake. To be able to make profit anyway it has to be allowed by EAM to skip the right shape of the domain landscape for a while. The service in question could be delivered from another part of the organisation. The correction of this inconsistency should happen when a team from the right domain can manage the preparation of the service the next time.

The correction of inconsistencies in business domain landscape is a task for the architecture owner (see next part of this series).

#1 – Pragmatic Enterprise Architecture – Value before strategy

All companies that use IT have an Enterprise Architecture (EA). Even companies that never invested effort into it have one, but this kind of EA is an accidental Enterprise Architecture.

Agile software development methods and frameworks are a new challenge for typical Enterprise Architecture Management (EAM). On the other hand, typical EAM is also a big challenge for agile methods. The current success of agile methods indicates that the importance of EAM will diminish or even dissolve in future.

EAM has still a right to exist in the agile world. The way it influences companies and business will change completely. A company that didn’t grow an explicit EA in the past can probably carry on without it in future. A huge IT landscape that has been operated with high EAM effort and whose IT organization is turning the agile way is experiencing a stress field between sustainment and change. Pragmatic EAM provides a reasonable solution for this stress field.

Pragmatic approaches in EAM can help an IT department to react fast enough to changing business needs. Hereinafter I will describe some aspects that support a pragmatic EAM approach:

Aspect 1: EAM must be valuable

Business before strategy. If your company is down and out because IT strategy didn't support business it's to late to praise strategy. Image source: Jörg Brinckheger /

Business before strategy. Is your company is down and out because IT strategy didn’t support business?
Image source: Jörg Brinckheger /

EAM is a supporting process that helps to reach business goals by using IT and it must create value that helps the company to reach these business goals. But, EAM often is handled self-absorbed, operates IT strategy without connection to business goals and, constrains IT projects more often than it’s helpful. This kind of EAM creates no value and must be stopped. Let’s assume there are EAM artefacts that are inherent from an EAM framework but have no stakeholders. There is clearly a gap between demand and supply.

One reason for this gap is that EAM isn’t adjusted enough towards business. Of course, EAM has the business in mind, but it´s focused on the business of the future. Once, future becomes reality this business is completely different from the plan EAM had in mind. This is just natural since EAM can’t forecast future better than everyone else. Even the Agile guys can’t – at least they have accepted it.

In this situation EA should be adapted accordingly. But, EAM is already occupied with alignment of IT landscape with some future step of EA and can’t solve the problem. As a result distance between business and EAM increases even more.

So what’s the solution pragmatic EAM would advise? It’s somehow obvious here: There is no sense in forecasting the future EAM or future business it’s a good idea spend EAM effort on todays problems. Don’t get me wrong: Of course it´s valid to spend some money and thoughts on next years IT strategy but only after EAM did everything it can to help to solve current IT and business issues. On the other hand, planning EA for the next five years in detail means simply throwing money down the drain.

Aspect 2: Business first

May be that’s one of the major issues with EAM: Typical EAM is unable to help to solve real world IT problems. Most IT projects depend on today’s practical Enterprise Architecture and IT strategy. But in case IT strategy isn’t aligned with reality anymore – and this is the case much to often – IT projects can deliver the second-best or third-best solution only. Business and IT decide to ignore IT strategy to be able to create the best solution. In consequence EAM isn’t taken seriously anymore.

In case there is pragmatic help from EAM this is because a lot experienced Enterprise Architects know about the disconnect and are willing to skip EAM or IT strategy dogmas. But, when it’s OK to skip what hinders projects, why do these awkward rules exist at all?

#05 – Agile Design & Architecture (Anti) Patterns – How to grow design

In my last post I wrote about how to kill design. Basically, I don‘t intend to kill design. I call myself still designer (and not design killer). I like to make sure that design evolves, becomes better and more useful. So, let‘s turn the question the other way around: In case I‘d like to grow design, how would I handle this?

Design the holistic way

The first thing would be to try to solve each and every design issue the holistic way. There is no sense in dividing a big design problem into lot smaller problems without paying attention to the original problem. You make sure you understand the design problem as a whole and when trying to solve its smaller problems you keep the effect of the small solutions towards the big problem in focus.

An agile mind would say: integrate early and often to make sure your solution works. But you know, those agile guys are really crazy.

Master best practices and building blocks

Before looking for a solution from my building blocks or best practices I have to ensure I understand both, the problem and my building blocks as well. This means I have to master both before thinking about solving a design issue. And, this is nothing I can learn in a three-days-training. You have to practice it a lot. On the other hand, you don‘t have to grow old before you should design a system. Actually there are a lot younger fellows around who are really quick in learning this stuff. Much quicker than I was.

Practice design all the time

The longer I stay in a team design becomes a rare event and my experience in design gets lost over the years. But before designers start switching teams all the time just to collect design experience it‘s probably a good idea to practice design on alternative ways. In an agile team you would do design all the time: bit by bit, step by step in a continuous process.

Another idea to practice design is by doing architectural katas. This is a two-hour session where you practice design for a given problem that has nothing in common with your current engagement. You do it together with a couple of peers. You solve the design problem alone or in pairs. After an hour you compare and discuss your solutions with your peers and by reflecting what you and your peers did you become better. If needs must you can do an architectural kata alone as well.

If you invest this time once a month you can be sure your design experience will grow, probably slowly but it will grow and it‘s a much better solution than doing design every two years.

Proof ideas by try and error

I have to admit, I don‘t like design documents at all. From my experience a design document is something that will prevent most teams from getting ahead. How often have you ever overheard someone saying: „We can‘t start yet. We have to write the design concept first“?

Doing so means you create an artefact beforehand you have no proof for whether it helps you to build the system your customer needs. I like to deliver a piece of working software for each design problem that occurs in my system. And, this working software should by something that is valuable for the customer.

Is a design document valuable for my customer? I‘m not sure, because I‘ve no idea whether it works or not. On the other hand, I’m sure I can’t ship a design document into production.

Of course, you have to think about design before you start coding, but this doesn‘t mean you have to spend a lot of time beforehand on an artefact that is out-dated before you start coding because some important conditions may have changed.

Respond to changing design needs

Customers need changes more often than we like. These changes influence the way our systems are build. We need to re-arrange packages, components or even sub-systems. We have to define new interfaces between technical or functional layers and, we need to have a lot of object oriented principles in mind that help us to keep our design simple and consistent.

The most important thing is that we have to make sure those changes happen in architecture and design of our system. All we have to do is to embrace this chance of change.

Balance design and customer demands

I‘ve just seen software systems where technical debt has been collected for many years. This is a heavy weight because it is expensive to change existing functionality today in that kind of system. To ensure that this technical debt disappears is an interesting task, but it’s not an easy one for sure.

In a healthy system you spend about 1/6th of your time for refactoring – this means two months per year per developer. Saving this time for five years doesn‘t mean you can solve the problem in five times 2 months because technical debt tends to sum up exponentially.

To be able to repair that kind of system you need a lot of time from the team thas is involved. Therefore it‘s necessary to find a balance between customer demands for new or changed requirements and repairing the system.

So the last idea to grow design is to ensure there is enough time left to maintain your system besides responding to new customer demands.

By the way, these are some ideas how design is handled with a more agile mind-set. I think this is something we need badly to be successful in the future.

#04 – Agile Design & Architecture (Anti) Patterns – How to kill design

A couple of days ago I‘ve had a crazy thought. I thought about how to kill design in a project in case I intended to do so. I came up with a simple six-step system that helps to kill design in each and every team. The execution order of the following steps isn‘t important. It‘s only important to try to kill design really consequently.

Solve design issues the analytic way

To kill design I would try to solve all design problems the analytic way: Concentrate on the problem itself. Divide and conquer bigger problems if needed – problem by problem. By doing so, I can pretend I‘ve solved each issue the best way I can. I simply prevent taking a holistic view and I will delay checking whether the resulting system itself will ever work until the latest moment. This way of doing design surely will send each system into trouble.

Use best practices and building blocks as a reflex

The next thing I would do is using best practices and building blocks as a reflex. Using best practices and building blocks is probably not a bad idea. But, by doing so really consequently I prevent thinking about design too much.

When focusing on solutions based on best practices I can pretend I understand the problem and deliver a quick solution. Whether this solution is a good one and may be adequate in future too is not my concern since I try to kill design. And, if I used only some my building blocks and only some best practices, I have a good chance to create an eclecticism system. That‘s a system consisting of parts that don‘t belong together.

Just to make it sure, I don’t mean design patterns or idioms. I mean

  1. best practices for system design styles like services or messaging
  2. building blocks for functional solutions like archiving or historiography
  3. building blocks technical solutions for security or authentication

This kind of solution in the wrong place is big enough to make your design stop working really quickly.

Don’t design too much

To kill design, please don‘t design too much. Designing a system each second year is clearly sufficient. This way I can be sure to have no real design expertise after ten years of practice. Just imagine an artist who paints a new painting each second year. After ten years he is surely not a master artist and I will be not a master architect as well.

By the way, using best practices as a reflex is also a good way that helps to prevent building up true design skills.

Hide behind a plan

Hiding behind a plan is another good idea to kill design. Let’s create a comprehensive artefact that describes how to handle design in detail. It will take months to write this document and helps to delay any team. This document will also help us to pretend that we have design in control allows us to deliver a plan and an estimation, at least until the plan changes.

Discovering that maintenance of such a document is costly is something the next generation of team members should do. When you realize that no one updated your design document in the last two years it‘s a strong proof that killing design has worked in this team.

Create design rules for everything

Another good idea is to create design rules for each design problem that may occur. Please, make sure to leave no room for creativity. This way you prevent that designers and developers think too much about the right solution. They only have to use your design rules and everything is fine. At least until someone realizes that your design rules tend to support the wrong solutions and your system is no longer maintainable. But, then it‘s already too late and killing design and design has already worked.

Focus on fulfilling customer demands

Fulfilling all customer demands is probably the single-best way to kill design. Customer demands are not that bad by default since they give your system a meaning. But by focusing on customer demands only, it is easy to build up technical debt. After technical debt has reached a certain level your system can no longer be adapted.

This time you killed not only design but your system as well. And, you probably will get a new chance to design a new system because it‘s clearly the fault of your customer and his continuing demands.

Choose architectural pattern the first possible moment

Thomas Vidic came up with another good idea to kill design: Choose the architectural pattern (event-driven, messaging, SOA, layers etc.) the first moment you can. There is a good chance your decision proves itself to be a bad one because you missed some important conditions and your decision constricts further evolution of design in your system perfectly. On the other hand, you prevent others from thinking about architectural alternatives too much.

Now you know my simple six-step system (plus one) to kill design. I think it can be applied really easily.

From a little distance this six-plus-one steps look really strange. It seems to me that design has been handled exactly that way in most teams I‘ve seen. Maybe I understood something completely wrong, since there was no intension to kill design in these teams. Hopefully.

In my next post I try to describe some thoughts on how to grow design instead of killing it.