Here is my big thought for the day:

The correct process implicitly guides people into correct behavior. The correct architecture forces code into the correct patterns.

A few weeks ago I wrote about how Tracer Bullet Architects show true leadership by creating clear and direct paths prior to the entire team coming aboard is probably the most important activity of a successful project.

However, I would like to take this one step further and suggest that if [as a team leader] you install the most correct process people will want to participate in correct and efficient behavior.

For example, when Napster was first introduced millions of people illegally downloaded music. Why? Not because they were bad people, but because they had no other mechanism for which to purchase (and own) digital copies of their favorite songs. Apple came along with iTunes giving people the first reasonably priced and easy to purchase model which included digital ownership – and the rest is history. People want to do the right thing and will given the correct means.

Building on this concept, it is possible to create project infrastructures that force developers to adhere to good practices such as SOLID. Seriously…I have done it. Some of these architectures would range from MVC/DI/IoC/Mock goodness to Tiered/Stubs/Statics/MockingIsEvil grossness, and each was a good fit given current company. It was the architectures that enforced clean lines of responsibility, increased testability, and [as a result] increased stability.

Of course people can break processes, of course they can break code, but if the correct solution is in place – they have to try really hard to do the wrong thing. If people continually are breaking process or code, then the answer is easy – you currently have the wrong solution in place.

Creating a zero friction environment is rarely rewarded by your peers; however, it is the most rewarding personal achievement one can accomplish.

If you do something correct, it is as if you did nothing at all. -God (as seen on Futurama)

Similar Posts:

• Companies Aren’t Progressive (But People Are…)
• Metrics and Wealth – It’s All Relative
• Why New Developers Should Consider Contracting
• The Blame Game: How Necessary Is Traceability?
• Don’t Go For The Doughnut

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

As Spiderman once put it, “With great power comes great responsibility”… well unfortunately there are a ton of roles and people that have never heard that phrase because I continually run into people who believe their current position entitles them to bossing people around while providing little value in terms of leadership. I am a huge believer of leading by example and as a result I have modeled my architectural duties around the Tracer Bullet Development tactic.

If you have never hear of tracer bullet development, it was a term coined in the classic The Pragmatic Programmer: From Journeyman to Master. In short, it is very important to trailblaze unknown territory through activities such as mockups, prototyping, and spiking.

However, I sometimes find “architect” level people providing no more worth to their team than a whiteboard full of boxes and arrows and a mouthful of hollow words of encouragement (sarcastic quotes explained). What teams need is clear direction on a clear path.

If what I just said wasn’t clear enough, let me be more blunt – whiteboarding and diagramming are the lowest forms of architecture and they provide the least amount of worth. I realize that I will receive some comment on how in their company is special and creating BUFD UML diagrams is key, blah blah blah. The point I am trying to make is, these activities 99% of the time are nothing more than echoes of the obvious – as a leader it is your responsibility to give direction to the non-obvious!

For example, the current project I am on we need to provide a very rich search capability. As an architect you could really suck and throw some buzzwords at your developer and send them on their way. You could suck less by throwing a couple of real technologies to a developer to give them a launching point for research, but more than likely you are delegating a very important architectural decision to someone who is not veteran enough to make the correct choice. The final option is, you do your job and lead by example by researching the alternatives yourself, picking the path, creating a prototype to validate your hypothesis, and then hand it off with a pre-cleared path.

In order to become a trailblazer, you have to blaze trails. Good architects do not blaze trails with their bossyness and whiteboard markers, instead good architects do it with their intelligence, code, and ability to communicate.

PS – Here are a few more tracer bullet resources, here and here.

Similar Posts:

• The Correct Process Guides Us (Tracer Architecture Cont.)
• Burning Down the Architect Title
• What Your Dog Can Teach You About Building Teams
• Do Managers Prey on Developer Pride?
• Book Review: Agile Retrospectives

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

A) Yes
B) Yes, but not without some changes
C) Why do you need to know?

For some reason, people are offended when people answer a question with another question; however, it is my belief that unless the question was given in great detail the answer may not be 100% correct (or correct at all for that matter).

A bad habit most developers have (myself included) is to be hasty in responses by non-developers. Rip off your headphones, respond in the most terse answer, put headphones back on, and turn back to your screen. Regardless if you are being disrupted, or you are having a bad day, here is why you want to engage most questions with another question:

Hidden Agendas Are Revealed

First and absolutely foremost, asking the question why is a defensive move. More times then not, when people ask questions in a vague, hurried, or terse manner it is to hide or cover the real question they are attempting to answer. And why are they hiding these details? Most of the time it is because they don’t want to know the real answer to the question, they want to validate the answer they most want whether it is the truth or not.

Asking them why slows them down and causes them to validate themselves. Most importantly, it removes you as the scapegoat. After all, the developers said we could…

Shows Interest In The Problem

Engaging in a meaningful conversation is perceived as high value activity to others because it shows sincere interest in helping them to solve their problems. As a result, you will be perceived as a high value employee because of your interest.

You Become A Valued Team Player

If you are perceived as a high value employee because of how you interact with the team, it only leads to believe that you will become a valued team player. Valued team players are generally liked and as a result promoted…and all because you answered questions with questions.

Answering questions with questions is only perceived poorly by those who are attempting to hide something whether it is illegal, immoral, stupid, or their own ignorance. Overcome all of these pitfalls by taking the time out to dig deeper and provide real helping hand.


Similar Posts:

• Refinance Your Technical Debt Just Like Your Mortgage
• Intellects Don’t Appreciate Intelligence
• Skull Candy Headphones – Heaven’s Gift
• Your Software Process Sucks : The Prelude
• What Football Can Teach Agile

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Without saying, I am impressed how intelligent geniuses such as Leonardo Da Vinci and Beethoven were; however, I am much more impressed how clever they were in applying it to their respective crafts.

One of the most prevalent examples of this is the underlying introduction of the Golden Ratio into art, architecture, and music.

Da Vinci used the golden ratio in a number of his works of art, his most blatant being his Vitruvian Man; however, he also used it in The Annunciation and speculated the Mona Lisa.

Beethoven’s Fifth is found with numerous instances of the golden ratio, as is Mozart’s sonatas. In fact, there is another whole discipline with the Fibonacci series called the Golden String which scrutinizes many violin constructions.

Before any of this – The Parthenon is filled with instances of the golden ratio and other mathematical wonders including optical modifiers.

For almost a year now, I have wanted to write about how software is much like the elegance of music. Both artistic from one perspective yet scientific and mathematical from another. So I continue by pondering the question – what would the Truvian Man or Parthenon look like if it were a MVC application stack?

With a quick introduction to the Golden Ratio maybe we can hypothesize. If the golden ratio equals:

The only positive solution to this quadratic equation is:

OK, now that we have that out of the way, normally we tend to draw a simple 3-tier architecture with 3 equal layers like this:

But what would happen if we apply the golden ratio to this architecture stack? Here are a few permutations:

The one that I hope represents reality the most would be this permutation:

So all of this brings up interesting questions, and lets assume you have your domain model layer completed.

First up, what is the optimal amount of software to support X number of entities?

This question completely depends on the application. Is it a simplistic data in / data out application? Then maybe your ratio of View to Model is closer to 1:1. Does your application have a ton of business logic? Maybe your ratio of View-Controller-Model is closer to 1.6:1.6:1.

Second, how does this change testing?

In the ROI of Testing I speculated at some values at the ROI of unit testing, business logic testing, and automated UI testing. How would that exercise change if your application demanded that you build the very top heavy permutation above (View layer is ~1.6 x bigger)?

In the end, does any of this matter? Being agile means only building the amount of software you need to do the job. If underlying patterns emerged – then neat, but not at all necessary to view the project a success.

500 years from now, I can only hope that someone goes through the hassle of dissecting my code and finding the mathematical brilliance of Beethoven’s Fifth…but in the end it will probably be more like Brittney Spears pop rock…


Similar Posts:

• Developer Faceoff: Sergio Pereira vs. Angelo Anolin
• The 7 Software “-ilities” You Need To Know
• Concentrated Codesqueeze: January 2008
• Book Review: Expert Spring MVC and Web Flow
• Book Review: Continuous Integration

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

Often I watch senior developers so hell-bent on preventing DRY through code abstractions, that they fall victim to the YAGNI principle. By being proactive you are opening yourself to wasting time creating abstractions that may never be needed or worse adding unwanted noise to your code.

Refactoring to abstractions should be a reactive response to DRY, not a proactive prevention plan. Being reactive to problems is a very “agile” approach, but even practitioners of agile processes sometimes get caught with their pants down running BUFD centric practices. To combat this problem, I created a term to help others overcome premature abstractions – Abstraction Harvesting.

Software is like a garden, you can’t 100% force or predict what is going to grow; however, you can react to current situations to better steer results in a favorable direction. The only rule of software abstraction harvesting is that you must have target software to abstract. What is the purpose of creating abstractions, if you don’t yet have the problem-solving concrete implementations? This is the equivalent of running the tractor over the field before the first sprout is even visible.

Before software can be reusable it first has to be usable. -Ralph Johnson

If we look closely at both DRY and YAGNI we find an almost sequential relationship. Without a DRY situation, we can not have YAGNI, but it is apparent that you can have a YAGNI situation without DRY. This is the equivelent of putting the cart before the horse. The concept of “Abstraction Harvesting” helps put the order back in place so you can prevent both DRY and YAGNI.

Have you been guilty of premature abstractions? If so, I want to hear the horror stories…


Similar Posts:

• You Never Should’ve Done It…
• Best of Codesqueeze 2007
• Abstraction Is For Both Humans And Software, But Not Software
• Bizzaro Development
• Does Satisfice Mean Agile?

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

1. Usability

Software usability can be described as how effectively end users can use, learn, or control the system. Some questions to ask yourself to determine usability might be:

• Is there a UI metaphor that I am using to help users adapt? (for example, the ‘desktop’ is a metaphor)
• Are the most common operations streamlined to be performed quickly?
• Can new users quickly adapt to the software without help? (is it intuitive?)
• Do validation and error messages make sense?

2. Maintainability ( or Flexibility / Testibility)

The definition of maintainability [for me] implies how brittle the code is to change. As a result, I tie the terms flexibility and testability into the overall maintainability of a project.

• Does the entire team understand the code base or does knowledge islands exist?
• Is the code throughly regression tested?
• Can modifications to the project be done in a timely manner?

3. Scalability

Scalability is the ability for your program to gracefully meet the demand of stress caused by increased usage. In short, ensuring your program doesn’t slow or bust when pounded by more users than you originally anticipated.

• What is your current peak load that you can handle?
• How many database records can create until critical operations slow down?
• Is the primary scaling strategy to “scale up” or to “scale out” — that is, to upgrade the nodes in a fixed topology, or to add nodes?

4. Availability (or Reliability)

How long the system is up and running and the Mean Time Between Failure (MTBF) is known as the availability of a program.

• How long does the system need to run without failure?
• What is the acceptable length of time for the system to be down?
• Can down times be scheduled?

5. Extensibility

Are there points in the system where changes can be made with (or without) program changes?

• Can the database schema flex to accommodate change?
• Does the system allow Inversion of Control (IoC)?
• Can end users extend the system (scripts, user defined fields, etc)?
• Can 3rd party developers leverage your system?

6. Security

I shouldn’t need to go into this one but to be thorough I like this definition of security: the measure of system’s ability to resist unauthorized attempts at usage or behavior modification, while still providing service to legitimate users.

• Does the system need user or role based security?
• Does code access security need to occur?
• What operations need to be secured?
• How will users be administered?

7. Portability

Portability is the ability for your application to run on numerous platforms. This is can include actual application hosting, viewing, or data portability.

• Can the data be migrated to other systems?
• For web applications, which browsers does your web app support?
• Which operating systems does your program run on?

Obviously, this is not an exhaustive list. There are many many more (Backwards compatibility, Interoperability, and Reusability to name a few).

What is your “-ilities” list? Which do you prioritize over others?

Similar Posts:

• The Most Reusable Piece Of Code Ever…Period
• Book Review: Don’t Make Me Think
• Software Teams vs. Superheroes: Why the Solo Developer is Dead
• Squeezed Links: August 2007
• Concentrated Codesqueeze: March 2008

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

While walking the dog, I listened to the .NET Rocks! episode with Roger Sessions on Enterprise Architecture. I expected the episode to be about enterprise level problems such as scalability and durability (and all the other -ilities). Instead Roger decided to pretentiously talk about his definition of the enterprise architect role. To paraphrase:

Right now, most businesses are split into two camps, the developers (technologists) and the business analyst. Companies think having two camps specialized is a good idea, but it is not…

The role of the enterprise architect is to understand the problem domain regardless if it is small organization or large corporation. It is a marriage between technology and business…

OK, timeout.

While I understand what he is attempting to say, and I agree that the separation of camps needs to blend [into the proposed marriage] for correct software to be built, there are a number of things wrong with this statement and a majority of this interview.

First off, please do not slap the word enterprise in front of any title unless you are specifically working on enterprise level problems. Using the terms enterprise and small organization in the same sentence is an oxymoron. If your job is load balancing the MySpace web farms then you may have the ‘enterprise’ moniker.

Second, attempting to understand your customers’ business domain does not bestow you the architect title because it is not exclusively an architect activity. I rarely meet a developer that has blindly developed off of a requirements document. Normally, the opposite occurs and passionate developers believe they understand the problem domain better than the client (which they promptly need to be reminded that this is not the case).

What I found most hypocritical about his architectural perspective was while advocating the a needed high level union of business and technology, he divided the technological camp by separating the roles of architect and developers. Developers are the ones doing the implementation, should we not be teaching them to learn more about the business domain? If we are segregating the technologists that know the business domain and those that do not, are we not just creating knowledge silos?

Too often I see the title architect incorrectly used for project managers with no technical skills or senior developers with no people skills. And now, I see the title enterprise architect being used out of context. When titles are misappropriated they start to lose meaning. As a result, the wrong people are placed in the wrong positions causing poor decisions.

In my mind, the architect role is about being the strongest team player, fluent in both the proposed technology but also the problem domain, but no more important than the single developer. The only difference between the architect and developer is the different altitude at which the problem is viewed.

Update: I mistakenly said David Hayden earlier but it was a recording with Roger Sessions. Sorry Dave!

Similar Posts:

• What Fraggle Rock Can Teach You About The Art Of Letting Go
• Abstraction Is For Both Humans And Software, But Not Software
• Why New Developers Should Consider Contracting
• The Illusion Of Technically Competent Managers
• The Officers vs. Sergeants Syndrome

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.

…the maximum elegance of any solution is bound by the language that we use to create it.

While coding in Ruby, it was interesting to see Scott Belware had the revelation:

…design patterns are bound to the programming languages that express them.

I like this thought as it is looking at the same concept from a higher level.

Similar Posts:

• How Did I Get Started In Software Development?
• Why Linguists Are True Code Artists
• Abstraction Is For Both Humans And Software, But Not Software
• Squeezed Links: December 2007
• Forced To Write English Syntax Code – Simplicity or Burden?

[Advertisement] - Atlassian provides zero-friction bug tracking and continuous integration solutions for software development teams. Visit Atlassian for free 30 day product trials.