YAGNI, it’s a very common term in development teams these days. Overused even.

However, in today’s more austere and economically challenging times, I have some new acronyms for you.

I’m not really up on popular acronyms so these may already exist in some form or another, but here are some more appropriate sayings that I’m saying/seeing more and more, together especially:

I Do Bloody Well Need It (IBLOWENI – ha ha) … but … NO-one’s Gonna Pay For It (NOGOPAFI).

I want to take a moment to talk about YAGNI.  YAGNI is somewhat of a natural extension to Release Early, Release Often which I discussed in my last post.  YAGNI tells you that “you ain’t gonna need it” meaning don’t over-engineer a problem and don’t add something until you know you’re going to need it.  You can find a little more discussion on it here.  It doesn’t mean that you should ignore good programming principles and just hack something together as quick as you can.  It implicitly says that you don’t try to anticipate what’s need.

Th principle applies to more than just coding, it also applies to actual working functionality.  Programmers (and people in general) are notoriously bad at predicting what they want or will need in the future.  Even if you do have a general idea that you’ll need it in the future, you probably don’t have a good understanding of the exact details and the kinds of problems that will come up.  It’s not a phrase that’s meant to be taken literally, but more of a something to take into consideration.  It’s easier to change something that’s simple than something that’s complex.  The key here is to be flexible to change.  For the most part you’re going to have pretty inaccurate idea of what users want.  Get something simple out there an let users tell you what they want instead of trying to do guesswork.

There are some notable times where YAGNI doesn’t apply, one of which is when there’s already a well known solution to a well known problem that you are just implementing (maybe in a different language, a different platform, maybe just for your own understanding).  An example is if you’re creating an RSA encryption program, the algorithm is well known, there’s been decades of research into it and you can be pretty sure that it’s not going to change any time soon.  Most of the time this isn’t the case, and you are dealing with unknowns, and it’s best not to guess when you don’t need to.

As far as Chefbook goes, after I defined the spec for version 1.0, I noticed that some of the data in my database schema I wasn’t going to be using.  I had anticipated the need for them, but I don’t need them yet, so I removed them.  I took out the ImagePath of a Recipe, because I’m not going to have the ability to add a picture to recipes initially.  I also removed the RecipeReview table (and the corresponding class) entirely.  I’m not even sure anymore why I put that there in the first place, other than the fact the recipe sites online usually have reviews, and I find them useful.  But initial release is a single-user app, and reviewing your own personal recipes doesn’t seem like a highly requested feature that’s worth spending time on upfront.  It can always be added later, so away it goes.  You can see the comparison below:

Old Schema

New Schema

You’ll also see that I fixed up some stuff as far as primary keys go, because a RecipeIngredient can’t exist outside of a Recipe, so RecipeId+IngredientId is the Primary Key.  Also to ensure that the RecipeId+CategoryId pair are unique, I did away with the artifical 3rd identifier and now recognize the pair as the primary key.  Choosing the right primary keys is important, and it’s good to get this kind of stuff out of the way early while still the the design stages because they are hard to change later.  Note that this doesn’t contradict YAGNI, because YAGNI doesn’t say be sloppy in your design.  Choosing the right keys isn’t a feature, it’s good design, and you’re always gonna need that.

Now there is one thing that I’m going to add where YAGNI truely doesn’t apply.  Now that I’ve already changed the database schema several times, it’s become quite obvious that I do need a way to transition data from one version of the database schema to another, and that’s not something that can be done just as easily later as it is upfront.  Even though for a working first version I don’t technically need a way to migrate data from a previous version to a newer version, not doing so could potentially leave users with the option of either not upgrading or losing their previous data, neither of which are acceptable, so having a way to upgrade from an older to a newer version with data intact is vital to the project and I will be added to the spec.

YAGNI (You Aint Gonna Need It) is a reminder to all who write software not to over engineer your designs, keep things simple, and add complexity only when necessary.

Usability, on the other hand, is about improving the users’ experience with the software—additional architectural complexity be damned!

YAGNI vs. usability are two forces that sometimes bump on agile projects.

This post looks at a simple example of how these forces can conflict, and how teams can help find the right balance for their project.

Keeping it simple

My last project was a web based application that showed users at a construction site which roads were closed on any given day.

One of the stories was called display road closures and the first version of the story looked something like this.

With a simple date based search at the top of the screen, the user simply enters the day they are interested in seeing road closures. They hit the search button, and the map refreshes showing which roads are closed, along with the search results at the bottom.

Delighting your customer

During development, my partner came up with a better way to visualize which roads were associated with which permits. Instead of simply displaying road closures in red, why not give each road closure a different color. And while we are at it, why not make the search results selectable—so that when the user clicks on a road closure at the bottom of the page, the associated road on the map becomes more bold and visible to the user?

I thought his idea was great. It required a fair bit of custom JavaScript, which would add some complexity to the UI. When asked how long he thought it would take, he said about an hour. Thirty minutes later it was done and integrated into the code base much to the delight of our customer.

Playing the YAGNI card

Deciding whether or not to implement this feature was a no-brainer. My partner had the necessary JavaScript chops, the cost was minimal, and our customers loved it.

But what if the trade-off wasn’t quite so black and white?

What if we didn’t know JavaScript?
What if the improvement, compelling as it was, was expensive to implement?
What if making the necessary change did require some heavy architectural lifting?

How should teams balance the desire of keeping things architecturally simple, with a desire to delight their customers?

See how you are tracking

Before getting all hot and bothered about whether to invest in an enhancement, or add a new feature, check and see how your project is tracking.

If your team is struggling to deliver stripped down, spartan versions of your customer stories as is, spending additional time on UI improvements is a luxury your project can’t afford.

On the other hand, if the team is on track, and the customer is happy with what they are getting, there may be a little wiggle room to make a few usability enhancements here or there.

And if your team is delivering ahead of schedule, all options are open. Go ahead and try the 13 shades of blue.

Know your project context

Every project is different. And not all have the same requirements around things like usability.

For some projects, a few fields and a submit button are more than enough. For others, nothing less than an aspirational experience will do.

Knowing ahead of time what your project requires, and how your customers feel about stories being ‘good enough’ will tell you whether you need to spend more or less on usability and the experience of the user. Putting working software into your customers’ hands sooner rather than later will serve you well.

Don’t be dogmatic

While YAGNI is certainly a sound architectural principle, like any sound principle it can be taken too far. When YAGNI is repeatedly used as a trump card to prevent improvements to user experience, it can upset team members, and cost the team an opportunity to better serve their customers. Not all usability enhancements need to be expensive, and sometimes the smallest of changes can make the biggest of impacts.

Like most things in life, it comes down to striking the right balance. The only way you’ll find out is if you build something, show your customers, and get some good solid feedback along the way.

Until then, you’re just guessing.

As programmers we tend to love and embrace complexity. Towering class trees and data-driven algorithms fool us into thinking we’re doing our jobs. That is, if you think programming is about writing code. I prefer to think of it as creating features. Not all features are the same, however.

Let’s take this method:

public String printCompanyName()
{
    System.out.println("Welcome to Global Dynamics!");
}

and compare it to this method:

public String printCompanyName(String name)
{
    System.out.println("Welcome to " + name);
}

It’s natural to view the second method as better. It has the added feature that the company name can vary. But this feature adds complexity and all complexity costs something. To make a decision about which method to prefer, we need to know how valuable the feature we’re adding is. Unused features are worthless. In this example, if the company name never varies throughout the program, we should use the simpler method.

This is the principle of YAGNI – You Ain’t Gonna Need It. Complexity always introduces cost so we should struggle to resist our desires to “improve” the system until we have a clear understanding of what the system should do. And even then, we should only do the minimum required to implement those features. YAGNI evolved out of the agile community as one technique for eliminating feature creep in programming. By only implementing the features needed today, programmers defer the cost of introducing complexity as long as possible. This same principle is stated in a different way in Test-Driven Development — programmers should do the simplest thing possible to get a test to pass. Complexity, when necessary, should evolve out of simplifying code, rather than complexity driving the creation of code.

We do this because complex code has several associated costs. Firstly, it’s a lot harder to change complex code than simple code. The cruft from complex code must be maneuvered around and creates confusion over where to add new code. This directly increases the cost of adding additional features. Secondly, complex code is harder to understand, which increases the cost of training new developers and also the risk of introducing bugs. And simply writing complex code in the first place is error prone.

There are some guidelines. If we only ever print the company name once, having a method to do so is probably wrong. Likewise, for classes, those that have only one child or that only have one method are likely introducing unnecessary complexity. Obviously these should be evaluated on a case-by-case basis, but these are pretty good rules of thumb. On the other hand creating methods and classes can reduce the overall complexity in a program by centralizing, encapsulating, and abstracting. The salient point is that these techniques should be used to reduce the overall complexity of the program. Refactoring should always be an attempt to reduce complexity by introducing structure.

YAGNI applies even when you’re looking at old code. There’s a comparable principle of You Didn’t Need It. When we speak of refactoring we usually mean the process of extracting generalities and creating structure, but it’s just as valuable to deconstruct over-complex implementations. It’s natural to think of the effort invested in creating a rich structure as a sunk cost but it is not. These unnecessary complexes silently intrude on one’s conceptualization of the program and make it harder to create new code. Often it’s more efficient to defactor code before extending it.

Defactoring is a term that has no clear definition associated with it. By defactoring I mean taking code and reversing the process by which it was refactored in order to return the code into less differentiated state. Defactoring is how I suggest solving the invisible design antipattern. Most instances of defactoring are followed by refactoring along different lines, but YAGNI dictates that step is only taken if there’s some clear need for the extra complexity. You might also think of it as attempting to reduce complexity by reducing structure.

While it is true that I view complexity as a necessary evil, I don’t view it as a villain to be fought at every turn. Rather, I view it much like mechanical engineers view friction. If we tried to build a program with no complexity, that program wouldn’t do anything interesting. But we must always be mindful of complexity as a force to be addressed and managed in its own right, on par with performance or defects.

Until next time,

Practice Makes.

A discussion that happens frequently on an agile development project is: “How much documentation do we need to create?”

One of the 4 values of the agile manifesto is ‘Working software over comprehensive documentation’.  Does this mean we have to write no documentation at all?  Most definitively not!  It means that working software has higher value than documentation.

If we embrace that value, what level of documentation should we maintain?

When searching the net on this topic, I found an interesting essay on the website of Scott Ambler.  It is called ‘The TAGRI (They Aren’t Gonna Read It) Principle of Software Development’.

He makes the comparison with YAGNI, which says not to add functionality that might be needed in the future. Stick with what is needed to get the current feature running, because the future functionality may never be implemented due to re-prioritization or changing business demands.

The TAGRI principle says: ‘Only model/document with a purpose and create agile documentation which reflects the true needs of the audience for that documentation’.

Please read the article to get the detailed explanation about TAGRI.

At my current project, due to the large set of complex business rules and the expansion of our team, we needed to create more detailed documentation.

This is why we created a central definition repository, which is a structure that more or less reflects the domain model.  Every domain object has a small document describing its properties, relations and behaviors.  All reference data that is used in several domain objects, is extracted and centralize in a reference document.  This makes sure that an update to a single piece of information is only needed in one place.  We refactored to this structure a month ago and will see how this works.

Francesco Cirillo, the inventor of The Pomodoro Technique, writes: “At the beginning of each day, choose the tasks you want to tackle from the Activity Inventory Sheet, prioritize them, and write them down in the To Do Today Sheet”. What considerations prioritizing of the activities is based upon, is up to the practitioner.

Stakeholders are the most important animal in the art of prioritizing activities. Who’s the stakeholder? What would make her happy? How can I fetch her opinion? End users are stakeholders, as well as the paying customer and the in-house product owner. And I can’t deny that I’m a stakeholder myself. I prefer activities which are challenging; that grow my mental capability. My pairing pal, my team, my project and my company are other stakeholders. And they don’t always share the preferred path to abundance. Will all these stakeholders – and some more not mentioned – put me between a rock and a hard place?

Every morning I pull activities from my Activity Inventory Sheet. The inventory must be short, not more than a week of work load. Stakeholders, including myself, can reorganize and change not yet pulled activities at any time. The pulling of activities, which I estimate to one day of work load, keeps me in sustainable pace.

MoSCoW is NOT prioritizing

Prioritizing activities is not the same as categorizing activities in prioritized groups. Prioritizing activities means that I have one single most important activity, and one single second most important activity, and one third most etc.

An example of categorizing activities in prioritized groups is the MoSCoW methodology, described by Jennifer Stapleton in her book DSDM, the method in practice: “MoSCoW is an acronym for the prioritisation that the requirements are assigned. The ‘o’s in MoSCoW are just there for fun. The rest of the word stands for: Must have, Should have, Could have, Want to have but will not have this time round”.

Personally I don’t like MoSCoW or other categorizing strategies. If a bunch of activities are in the must-bag, how can I know which one that is most important? And when I have done all in the must-bag, should the could-bag items be moved to the must-bag, or what? A straight prioritized list is much more crisp and clear.

Choosing Activities and ROI

Return of investment (ROI) is the ratio of money earned relative to the money invested. This measurement can only be known afterwards with twenty-twenty hindsight. In order to prioritize I need to second-guess the numbers. Since I don’t actually see the money I also have to translate money into something else.

Invested money could be translated into expected number of Pomodori needed to complete this activity. It could also be translated into how complex I think this activity is or how much knowledge I have about this problem. I’m aware of that these measurements are not interchangeable and in reality I weigh and mix different measurement methods.

Prioritizing Strategies

Below is a list of prioritizing strategies that I, in a pragmatic way, have to combine:

• Most-Valuableish – If the stakeholder only got one thing from me, this one would be the most valuable.
• Make-ends-meetish – Some activities are the final piece of a big puzzle. If I complete this activity a whole feature is really done, and not only 90% done. The customer can start collecting the cash.
• Smallish – Activities that can be completed in less than a Pomodoro can be summed up and done immediately. This will get them out of sight and also give value sooner.
• Just-In-Timeish – Kiichiro Toyoda´s lean principle reduces waste by producing exactly the quantity that is needed. I choose the activity with the closest due date and that is most asked for today.
• Pregnancyish – I need to do some initial work effort just to kick off the fermentation. Then I have to wait for a predictable amount of calendar time before I can convert the dough into donuts. So I better start the initial work effort soon.
• Empty-Walletish – In some sense this activity is closest to go for free. I won’t disturb any other person, I don’t need to introduce any new tools, and I won’t trouble any existing production code.
• As-Easy-As-Pieish – This activity is located in the hood where I grew up. I know everyone and everything related to it and all its history. These kinds of activities are good candidates for navigating a pairing driver, to share my knowledge with the team.
• Digging-Deeperish – To minimize the number of things in process, I will consider starting brand new activities as maybe harmful. Instead I prefer working on already started ones.

Prioritizing Strategy Anti Patterns

Then there are many, many anti pattern prioritizing strategies. Most of them are smells of dark hidden agendas:

• Virginish – The activity that contains most new, rare and seldom-heard-of technology is the most exciting one, especially if this particular open source library can add a CV ornament.
• Avoid-monster-In-The-Closetish – It’s impossible to start with something that isn’t investigated in detail – from seed to harvest. This is actually a denial of the difference between development and manufacturing.
• No-Pig-In-A-Pokeish – The activity with most approximate How, When and Why is the one to start with. The rationale is that to delay this activity could prove later that I’m building waste right now. Under evil circumstances, eliminating risks is an anti-pattern that drives me into up-front-guessing instead of preferred evolutionary thinking.
• Stackish – Last in will go first out to the workbench. To immediately follow-up every single event that expects me to do something will make me stand without any completed result in the end of the day.
• The-Early-Bird-Catches-The-Wormish – First in goes first out is the same as never re-prioritizing. Always work on the eldest activity is over fair, and it will definitively not maximize the gained value to the customer.
• Round-Robinish – To do a little here and do a little there and fix a little here and fix a little here is demonstrating decision unawareness. No activity will be completely done, but many will be started.
• I’m-No-Spring-Chickenish – Choosing the activity that will impress most on my pals will probably give the application a nice bells-and-whistle user interface, but no functionality.
• Am-I-My-Brother’s-Keeperish – Politicians usually have a hidden agenda. Some argument comes from their mouth, but the real purpose to start an activity is to put them self in a better position for the future. Cynical, for sure.
• Waterfallish – First fill a big barn with appreciated activities to do. Then not only make a prioritizing schedule, carve it in a never changing rock. And finally follow this plan, even if the sky falls down.
• Arousalish – The activity that feels most fun to start with, is the one to start with – no mater how valuable and how expensive it appears to be.
• Frameworkish – Activities that does not return one single pfennig now, but are expected to make it easier to earn value in the future are only important if you are the real Oracle of Oz. And not even then, since Judy Garland fond that the truth behind the veil was a small man. Instead: think YAGNI.
• Lone-Wolfish – No stakeholder asked for this activity to be done. No one even understands what it is and what it will be used for. But, still a troll is sitting in his cubicle and doing this. And surprisingly a lot of people think he’s so clever, just because they don’t understand what he’s doing.

Conclusion

Many different ideas, assumptions and agendas can control the way I’m prioritizing my activities. If I want to be decision aware, then I need to recognise the sweet scent of flowers as well as the smell of prioritizing strategy anti patterns.

Additional facts:

• The DSDM consortium does not seem to wanting its defined wisdoms spread unlimited as they write on their site about the project management framework Atern: “To sell Atern training, consultancy using Atern as the vehicle, or to be a tool provider for Atern, it is necessary to become a DSDM Licensed Reseller.”
• Kiichiro Toyoda – the son of Toyoda Loom Works founder Sakichi Toyoda – resigned from the company in 1948, at the age of 54.
• The American Heritage Dictionary of the English Language tells that a stakeholder is either “One who holds the bets in a game or contest” or “One who has a share or an interest, as in an enterprise”.
• The Yerkes-Dodson Law says that there is an optimal level of arousal for doing maximum performance.

Hittade en intressant bloggartikel om YAGNI-principen för design av mjukvara: You Ain’t Gonna Need It. Det är en princip som jag tagit till mig sedan några år tillbaka och är starkt positiv till, en av mina tre “programmeringsdygder”, tillsammans med DRY (Don’t Repeat Yourself) och KISS (Keep It Simple, Stupid!). Den sista är iof. närbesläktad med YAGNI, kanhända droppar jag den ur listan en dag..

Taggar: programmering, YAGNI

I’m in debt to Giovanni Asproni for this new acronim. But the fact behind the term is very well known here.

Let’s start saying that it’s a matter of fact, although a sad one, that a lot of enterprise projects are poor designed.

But, as strange it may seem, in my career I (almost) never saw a simplicistic design, they are all wrong on the over-complicated side.

So why is this happening? If they were all producted by morons, they ought to be equally distributed on both side of the Gaussian. Also I have anectdotical evidence that not everybody in the contractor world is a moron (honestly!).

So, as you may have guessed, the reason behind it is a little more complicated and it has Darwinistic-like reasons.

As contractors’ life goes, you need to keep your resume always updated to the latest hype and keywords in order to be recruited. And simply you don’t have enought spare time to learn everything, so…
a solution appears misteriously in front of you: Put whatever is the current buzzword in your next design document.

Add some new fancy framework or library to your current project, and learn it, test it, experiment with it at your usual tariff.  It’s brilliant and convenient!

I’m not sure to blame only the contractors, it’s a response to the market absurd rules. If customers were looking for developers who know how write simple and elegant code, they would get exactly that.
Instead they usually hire developers with the most buzzwords complete CV. And at the end, they will obtain CVDD applications. Unnecessary complicated, with tons of once-popular frameworks, often misused, etc. etc.

Disclaimer: in case you’re considering to hire me, I would never do anything of this sort!

Atenção, este blog foi migrado para: http://brunopereira.org

No meu tempo de experiência com Java EE já pude aprender e constatar bastante coisa. Um fenômeno que se repete com freqüência é a escolha de servidores e componentes que contêm muito mais do que se necessita para a resolução de um problema específico.Um exemplo claro disso é em aplicações que não precisariam de absolutamente nada que o Tomcat não ofereça, mas a escolha padrão acaba sendo um servidor de aplicações “mais parrudo”, como JBoss, WebSphere ou Weblogic. O curioso é que estes últimos servidores de aplicação suportam uma quantidade bem mais ampla de especificações e oferecem bem mais recursos, mas o que eles realmente oferecem de diferencial não é o que está nas especificações, na maioria dos casos.

Muitas vezes o diferencial destes produtos está em funcionalidades nos quais eles excedem as especificações e oferecem facilidades que não são obrigatórias. O fato de oferecer estas funcionalidades extras é muito bom, pois isto traz mais qualidade aos clientes, e isto possivelmente melhora os processos internos do cliente. Apesar disso, é comum vermos escolhas de tecnologia serem feitas porque a opção A oferece muito mais recursos do que a opção B, sendo que na prática as opções oferecidas pela opção B serão plenamente suficientes para atender a todos os “problemas reais” que virão a surgir. Isto quer dizer que é comum a opção A ser escolhida em vez de B sem que se saiba quais recursos de A serão úteis de verdade, mas pela percepção que “A oferece mais do que B”.

Talvez a justificativa para este comportamento seja escolher uma opção que “possua todos os recursos que necessitaremos”. Consigo entender isso. Porém, isto traz o caso comum de usar uma bazuca para matar uma mosca. Sim, com a poluição e evolução das espécies, podemos no futuro encontrar super moscas mutantes do tamanho de um helicóptero, e neste caso espero que você esteja com sua poderosa bazuca para matar essa mosca monstruosa!

Entretanto, para as moscas que eu costumo encontrar, um mata-moscas de plástico resolve o problema. Além disso, eu sei usar bem um mata-moscas de plástico, e foi bem mais fácil de aprender a usá-lo do que aprender a usar uma bazuca. Por oferecer bem menos e ser bem mais simples, o modo de operação do mata-moscas de plástico é algo que uma criança consegue aprender. Já para utilizar a poderosa bazuca matadora de moscas mutantes, é bom ler direitinho os manuais de utilização e se possível fazer o curso prático para fixar bem os conceitos. Afinal de contas você não quer correr o risco de se deparar com uma mosca mutante e não saber usar a bazuca né?

Da mesma forma que as moscas, as aplicações corporativas possuem este tipo de fenômeno. Antes de conhecer as necessidades reais da aplicação, já se definiu o uso do Weblogic com Oracle e possivelmente a configuração de um cluster de alta disponibilidade. Talvez fosse uma aplicação pequena ou média que o Tomcat + Derby ou Postgres ou Mysql pudesse dar conta sem problemas.

Eu venho estudando muito sobre web services nos últimos meses. Também nesta área isto ocorre bastante. Sem conhecer bem as necessidades que se quer resolver, já foi escolhida a pilha de componentes que “oferece tudo de web services”.

Este fenômeno é global, ocorre no mundo todo. Opiniões interessantes sobre isso foram dadas por Bill de hÓra e Rod Johnson. Uma abordagem que pode ser tomada é tomar as decisões de tecnologia baseando-se nos requisitos já inicialmente definidos. Pegar os requisitos funcionais e não-funcionais iniciais da aplicação e então decidir as tecnologias a se utilizar parece uma boa escolha. Desta forma, você possivelmente fará boas escolhas sem trazer desde o começo uma complexidade e custo que possivelmente nunca seriam necessários.

Claro, existem casos em que realmente se utilizará extensamente os recursos avançados do Weblogic e do Oracle, e eles são de fato necessários. Da mesma forma, podem existir web services com altos requisitos de segurança e confiabilidade que te façam depender de recursos do stack WS-*. Se este for o caso, escolha mesmo as opções com mais recursos e utilize tudo que precisar para atender aos requisitos críticos que lhe forem apresentados. Porém, saiba que estes casos são a minoria dentre as aplicações corporativas existentes mundialmente.

Se o seu problema for algo mais comum, escolha produtos e componentes que resolvam bem os problemas apresentados, e se algum dia eles deixarem de atender às necessidades, pondere novamente as suas escolhas. Isto sugere o “Grow as needed” do título. Cresça a sua estrutura conforme necessário, não compre inicialmente uma bazuca se ainda não existem moscas mutantes. E se os seus problemas não mostram claramente a necessidade da bazuca, aí provavelmente surge a sigla do título: YAGNI (You aren’t gonna need it)!

Antes de escolher as opções “mais ricas e robustas” disponíveis, estude se opções mais simples são capazes de resolver os seus problemas, pois se isto for o caso, você provavelmente terá uma configuração mais simples e mais barata e cheia de pessoas capazes de manipulá-la. Isto é melhor do que depender vitalmente de algum fornecedor e precisar contratar o super especialista que é um dos poucos no mundo capazes de resolver seus pepinos.

E claro, se suas decisões puderem ser de componentes open source, você não pagará nada de licença de software e terá uma grande variedade de profissionais disponíveis para te oferecer serviços

Every software developer has heard about the Gang of Four and their classic Design Patterns book. It’s really a must read for any serious OO developer. Awareness of (and more importantly the judicious use of) design patterns is rapidly becoming a prerequisite for writing code in the first place, like breathing or a high tolerance for caffeine.

However, I personally believe that over-reliance on design patterns leads to bad Agile practice. Let me give you an example. There’s a pattern called Dependency Injection, aka Inversion of Control, which decouples a client from the implementation of a helper class. Martin Fowler covers this in mind-numbing detail here, along with a related concept called a Service Locator. The main problem, from an Agile point of view? When you really get down to it, it just moves the dependencies one (or more) levels away from the class in question. You still have to have that information somewhere.

Dependency injection is an easy concept which rapidly gets out of hand in the endless “what-if” brainstorming that happens from time to time when a few smart and excited software geeks get together. You’ve heard it before: “Let’s just encapsulate this code in an abstract base class that inherits the ILookup interface…”

One should assume that this is a prima facie violation of YAGNI unless there’s a clear customer requirement that couldn’t be met in a more direct way. Extending a bit, most of the patterns that add complexity at the expense of understanding should probably pass the YAGNI test before you jump ahead with them.

You may ask, “Doesn’t this lead inevitably to sloppy / spaghetti / cowboy / repetitive code?” Remember, Agile is not about No Design, it’s about Just Enough Design. And testing. And doing what the customer wants, not what you think they will need X years from now. And iteration. And lots of other practices, most of which tie together to help the entire concept work.

I have the word “architect” in my title at work, which is cool cause it apparently means I know what I am doing but is bad because it means that people assume that I always know what I am doing.

I consider myself a pretty good software engineer, in that I can generally produce working software against the requirements given to me. I actually do not tend to be up on the latest trends in WS-* or frameworks, etc so most of my code is pretty straightforward (I hope). Thankfully others I work with (both at work and on hobby stuff) keep up with things like Hibernate, Spring, Quartz so it allows me to keep track of what people are actually using, versus what the hype is. I will shamelessly take the skeletons of how those systems are used by other co-workers and friends. However, I always try to figure out how to make using them easier if I find bits that are in any way non-intuitive.

I tend to write in an “agile” way. What this really means is that I think about the problem and do some drawings, pseudocode, sketches, pictures, whatever that I need to get something up and running that solves an immediate problem. Then I move on to other components. Realize that I missed a detail. Rinse. Repeat As I move onto other requirements I integrate them with my solution and always try to have a working system that does something.

Back to the point of my story… this is a horrible way to work if you are supposed to “architect” (in the sense of “here is the design, build it”) a system based on a set of requirements. It is very easy to draw some lines and boxes with cool names and leave the “details as an exercise for the programmer.” Bad idea. By the time it has made it to the programmer (unless they work intimately with you on your own team) many of the requirements have been lost, and they are left only with the design. So they implement, or try to implement, what has been given to them. And surprise, surprise, it meets the requirements but does not actually work.

This is when I realize that what I really gave was a design for a “first pass” that would really be a prototype of the system. If I were implementing, it would be easy to turn around and enhance to go to the next level. But in this case, it has already gone down through two other levels of tech lead and off-shore architect. So not very easy to say “ok, so that we aren’t quite there yet, we actually have a million other details to work out”.

So lesson learned there is that however long you would normally give yourself to “design” the system, multiply it by 10 so that you can basically look at every single API and external system being called, and run through every use case you can think of to see if the design does in fact meet the requirements and produce a working system. It really is not enough to see that API X has a method that looks like Y and takes parameters A and B and probably does Z. What happens if you have 1 million sets of {A,B}?

My real point, I suppose, is that being fairly good at designing and implementing your own systems does not make you an architect. And if you are in that position, do not let someone tell you that you only need “maybe a day or 2″ to design something if it is of any real complexity (where a good way to measure complexity is how many interfaces exist between various systems). Give yourself at least a couple of days per non-trivial interface.

I hate the feeling of thinking that if only I had had more time my architecture would have been perfect after the first implementation. I hate even more the feeling that it honestly probably would not have been. It is never right the first time.

Or maybe I just really suck as an architect.

In any case, I am currently getting to do the implementation on a quick-turnaround (aren’t they always in the corporate world?) implementation and I am absolutely loving it. Sure, the deadline is quickly approaching. But you know what, it is my project to succeed or fail at. I am using parts of the system that I “architected” and seeing parts where I totally did not think about the problem in low-level enough detail, and trying to fix those oversights. I am getting to play with systems that I have not worked on previously. And most importantly, I am getting to code! Maybe it is the design aspects of the coding I enjoy, but I think not. What I really, truly, absolutely, love is seeing something grow before my eyes into a working system. I love the list of “//TODO” items (and love even more removing them as they get done) and bits of stub code. I love when I get surprised that it works even better than I expected. I love making a database query 10,20,30 times faster through simple application of a decent index. I love keeping 10 things in my head as I move from file to file and implement my ever-growing APIs.

I have no doubt that my methods would scare many of the purists out there. At heart, I am a “just-in-time” developer. For my emulator, I did not implement an instruction until I ran into my “not yet implemented!” exception. Same goes often for other things that I implement. It is a bit of an extreme example of YAGNE, I suppose.

Update (11/30/2007): Added some words I have left out.

Ran across this post and had to preserve it for later reference. I wonder if I could get a T-Shirt made…
(Nod to Scott Belware for the link) 

Donna and I have very different approaches to hanging out the washing. I like to take each piece of clothing individually and make sure it’s straightened, right-side-out and hung so as to minimise ironing etc. Donna likes to get the job over with as quickly as possible, and leaves the straightening and right-siding until the moment before wear.

We’re both right, of course, and we can both defend our approach as ‘agile’: Donna “decides as late as possible”, whereas I “refactor” as I go. We can each also see the problems inherent in the other’s approach: I waste time folding just-washed underwear, and Donna wastes time later unravelling it in order to get into it.

We’ve each been doing it that way for years. Probably neither of us will ever change, and there’s probably no reason to. These are simply old habits, and they do no harm. But hanging out the washing tonight made me think again about trying to persuade a HeriocProgrammer or a WaterfallManager to TestFirst or IntegrateOften…