Derik Whittaker : Opinion

Its all about communication, not processes….!

Derik Whittaker — Wed, 18 May 2011 07:34:00 GMT

We live in a world where thoughts and concepts are not getting smaller and simpler but rather they are getting larger and more complicated. Software teams in many cases are no longer all crammed into one room or can be fed by 2 boxes of pizza (which is a large systemic issue in my opinion). Teams are now spread out over many floors of a building (if your lucky), over many buildings in a city, or in most cases over many times zones spanning the world.

As our teams become larger and the problems we are trying to solve are becoming harder one thing remains paramount to success, communication. You can put together the greatest group of talent you can find but if the teams do not communicate effectively they are not going to be successful.

It is funny that I am even having this thought stream because we live in a world where communicating with people has never been easier. I can turn on my phone and call someone, text someone, IM someone, tweet them or update their wall on facebook….all from the palm of my hand. However, teams are increasing becoming worse and worse with communication and this is going to be the downfall for projects which otherwise would have been successful.

What is funny (or sad I guess) is that of all the problems we attempt to solve every day this is by far one of the simplest and easiest and requires almost NO real effort. The problem is people are either inherently lazy and do not want to expend the energy to communicate or are guarding this information because they feel it provides them a source of power or security. By being either lazy or secretive what they are really doing is signing their own death certificate for that project.

Software teams (all teams really, but you get the idea) need to make it their #1 priority to ensure that all information, useful or not is communicated to the ENTIRE team at ALL TIMES. But how do they do this?

By:

Communicate to the ENTIRE team at one time, do not allow the trickle down theory to rule your team.
Communicate EVERYTHING even if you are not sure how important it is
Communicate CLEARLY and CONCISLY important decisions and dates
Communicate in person when at all possible, don’t relay on email or discussion boards (this is difficult w/ distributed teams but make it work)
Do not create paragraphs of information where bullet points will work better

Just a few of my thoughts.....

Till next time,

Noisy code does not equal clean code

Derik Whittaker — Fri, 26 Feb 2010 01:16:00 GMT

Today I was having a conversation with one of the developers on my team (btw, this guy is going to be a rock star) and I made that statement to him that I thought we had some noisy code. The context around this conversation was with our usage of AutoMapper (which I love so DO NOT take this as a slight against the tool) and how by default using AutoMapper exposes too much noise and I do not like it.

When I made this statement to him he was not 100% sure what I meant, so in place of having a one-off conversation with him I thought I would try to explain my thoughts to the world (hey, that is the point of blogging after all, right).

When using AutoMapper to map objects from one type to another in your code you need to implement something like below:

var someMappedDto = Mapper.Map<SomeModel, SomeDto>(someModelInstance);

If you look at the code there is a bit of noise here in my opinion. So what do I mean by noise? I consider anything in my code that gets in my way or does not provide me direct feedback as noise.

In the line above I consider the following noise:

Mapper.Map – I do not like this because having Mapper.Map sprinkled all over my code base just means that my code has too much knowledge of the actually mapping library we use, this is noise. Hey, it was for this basic concept that the Common Service Locator was created to help prevent
Having to provide both the source type AND the destination type – The source type should be able to be derived from the source object instance (in cases where you do not want to use the mapper for some child type of the source type). I concede that you do need to provide the destination type other wise we would have no clue what you want in the end
Having to provide the source type instance in the constructor.

In order to reduce the noise, and make for cleaner code I would like to see something like

var someMappedDto = someModelInstance.Map<SomeDto>();

In my humble opinion the code above is cleaner and more concise. The code above has less noise to distract me from my coding efforts. In particular the code above addresses my 3 issues in regards to the noise

Now I am abstracting my mapping library of choice (AutoMapper) away into an extension method some place, thus giving me a clean abstraction layer
I do not need to provide the source data type as it can be inferred from the instance itself (yes, only in the case where the actual type being used is the type I want)
No need to provide the type to be mapped from (well not directly)

To me noise free code is clean, concise and easy to read.

Till next time,

A new feature request for C# I would like is fall through exceptions

Derik Whittaker — Wed, 20 Jan 2010 23:58:16 GMT

Now before you write off this post as being ‘just another silly request’ hear me out.

Right now in C# we can do the following

switch( someObject )
{
	case Option1:
	case Option2:
	case Option3:
		// do something
		break;
	case Option4:
		// do something
		break:
}

Allowing fall through for a switch statement is a powerful technique. It allows for multiple case statements in the same switch block to use the exact same logic, oh, and it also allows for code reduction.

Given the fact that we can do this with a switch statement why can we not do this with try-catch statements?

As an example(s) (or a suggestion of syntax) why could we not have the following

try
{

} catch ( SomeException1 ) {
} catch ( SomeException2 ) {
} catch ( SomeException3 ) {
} catch ( SomeException4 se ) { 
	// do something
} catch ( SomeException5 se ) {
	// do something
}

try
{

} catch ( SomeException1, SomeException2, SomeException3, SomeException4 se ) { 
	// do something
} catch ( SomeException5 se ) {
	// do something
}

I know, I know you think I have lost my mind. But think about it. There are times when you want to handle multiple exception types with the exact same logic. However today when you do this you are forced to either create a helper method to handle the logic or repeat the logic over and over again. If we had the ability to allow for fall through exceptions we could reduce duplicated code and reduce code noise.

Now before you start asking questions like … let me provide some quick Q & A

Q) If you do this you will never be able to know exactly what type of exception was thrown.

A) You are correct, but in this scenario do you really care about the exception type? If you did I am going to guess you would break it out into individual catch block

Q) When would this situation actually be practical?

A) Consider this. You are creating a connection to a 3rd party resource (web service, wcf, api, etc) and that connection can throw a few different exceptions. In some cases if the expected exception is throw you want to log and maybe roll back a transaction or something. In this case i do not want to re-throw (or just let bubble up) the exception, but at the same time I do not want to duplicate my code.

So, let me have it. Tell me how dumb this is.

Tell next time,

It takes real balls to do it right

Derik Whittaker — Fri, 06 Nov 2009 10:57:19 GMT

It does not take a genius to realize that I (and most others on this blog) are fans of JetBrains. But what it may take a genius to realize is it takes balls to do what JetBrains does with their products.

You may be asking what exactly I am talking about or referring to? I am taking about the fact that they are willing to throw caution to the wind and provide very early (and in many cases mostly stable) release of their products to the wild. What makes this even more crazy/impressive is that they build products for software developers and we all know that software developers are the most vocal and opinionated group of people out there.

The fact that JetBrains releases software early and often simply makes sense and ALL companies that release software (regardless of the type) and not be afraid of what may happen. Because putting your product (in this case software) in front of customers early and often will allow you to:

Find and resolve more bugs
Find and resolve any weak area in usage or workflow
Find areas of the application that are still lacking

Now the trick to releasing pre-alpha, alpha or even beta software is you MUST listen users feedback and attempt to incorporate or fix any areas of concern (of course only make adjustments if they make sense for the product).

So, what is the point of this post? Well 2 things. 1 to give kudos to JetBrains for again releasing early copies of their software and 2 tell all software companies that releasing early and often will result in a better product.

Till next time,

Without Context everything is suspect

Derik Whittaker — Mon, 19 Oct 2009 12:02:52 GMT

Over the weekend I was having a conversation with my wife and we were not communicating on the same wave length. After a few minutes of talking in circles it dawned on us that we had not established the context around the conversation and we had no real understanding of what either of us was saying. This lead to remember a time a few jobs ago when ‘lack of context’ lead people to draw the wrong conclusions about a forth coming client visit.

The background for this little story goes something like this. We had an existing client of ours that had an internal development project underway and they wanted us to come onsite to gain a better understanding of this project as well as to see how our product could integrate/play nice with their project. Prior to meeting with the client (in person or via a phone conversation) we were presented with a power point presentation which laid out the ideas and intent of this project. Now keep in mind that this power point was not created specify for our viewing, but it was very, very relevant in respect to the projects goals and aspirations.

As this was the first interaction (from a product development standpoint, not a sales standpoint) with this given client our team had no background or history to draw from when reviewing the slide deck. As we were reviewing the deck the entire team stopped at the page that was titled ‘Rules of the Game’ and had a few bullet points which said things like ‘Don’t ask dumb questions’ and ‘Don’t make this harder than it has to be’. Immediately upon reviewing this deck we all go the impression that this meeting was going to be rough and that the client was going to be a little bit on the difficult site.

Fast forward a few weeks till when we were able to get onsite with the client and have a conversation with them. During the initial stages of the meeting the client was doing a white board session (which I love when a client does this) about their goals and what they had in mind. During this session the CIO started to go over the ‘Rules of the Game’ with the group. However, this time because we had more context to go on our perception and understanding of the rules changed 100% percent. The context of the conversation was not pointed towards us, the product team. But rather about how he did not want the application to get in the way of the user by 1) asking dumb questions or 2) making their life harder than it needed to be.

About 30 seconds after our client was finished with his whiteboard session the team members all kind of looked at each other and all came to the realization that we had misinterpreted the the message based solely on the fact there was not context in the power point deck. This realization was great, because now we fully understood the client as well as their intent. It also made us feel a little better because we had gone into the meeting expecting there to be a bit of hostility and in fact the exact opposite was the case.

The moral of the story is this. Context is a powerful part of any message. If you do not clearly communicate the context in a clear and concise manor you are leaving your messages up for interpretation and this can lead to bad things. The same holds true not only for emails, but also for your code.

Till next time,

Testing only the code of value

Derik Whittaker — Wed, 07 Oct 2009 11:48:25 GMT

I am 99% sure I have had a post like this in the past, but my google-foo was weak today and I could not find it. Do not let anyone blow smoke up your back side, testing is expensive, testing takes time but most importantly testing can help improve the quality of your code.

If you are going to spend the time and money to create automated, rerun-able unit tests make sure you spend your time/money wisely. Make sure you test the code that matters, test the code which is complicated (keep in mind a LOC count does NOT equal complexity).

Today when scanning some code in another part of our project I came across this tests:

public void AdminSetIDTest()
{
	var target = new CreateTaskActivity();
	int expected = 50;
	int actual;
	target.AdminSetID = expected;
	actual = target.AdminSetID;
	Assert.AreEqual(expected, actual);
}

When I looked at this tests 2 bells immediately went off in my mind

The name of this tests SUCKS BALLS and does not clearly convey the intent of the test
This is testing that a property getter works (no, there is NO logic behind the getter/setter)

If you disregard #1 from above for now (but remember clear/concise names do matter) and focus on #2 this tests adds no value to the test suite. All this test is doing is ensuring that the .Net framework does its job. This test is a total waste of time and energy and can actually cost you more time/money in the long run because you may have to change the useless test over time as you refactor.

The key take away from this is simple. You always have limited time and money when trying to get a product out the door. Unit testing IMO can always help you to create a better product, but make sure you use your time and money in a way in which will allow you to maximize your ROI.

Till next time,

The Sky is falling, the Sky is falling…. Or is it?

Derik Whittaker — Wed, 30 Sep 2009 14:25:49 GMT

I assume everyone is familiar with the children's book Chicken Little where the chicken little had an acorn fall on her head and she just assume the entire sky was falling so she ran to the king to tell him such. Well, sadly too many times people in our industry do the same thing.

Today I received an email from one of the product owners in my product group stating ‘the entire build & deploy process is broken and is going to cause our project (which is slated to go live in late 2010) to miss its deadline’. WOW, what a way to start off my day (oh yea, he CC’ed up the entire food chain).

Now since the build server has been mostly stable for months and I had not head too much from this team in terms of the build/deploy process I was a bit taken back about this. At first I was kinda worried we may have an issue. However, calmer heads prevailed about 10 seconds into my thought process and I realized this may be an email with no or little merit. I decided that before I spent any time looking into the issue I needed more information. I needed to know exactly what was failing, when it started, why I had not heard about this before, etc, etc. So in order to possible head off anyone the food chain from also reacting as the sky was falling, I politely asked this PO to clearly state each of the problems they are experiencing and when they started to experience them and only then could we take a look at the email and take it serious.

The point of this little story (apart from allowing me to vent) is to state the obvious. If you find yourself in a situation where something is wrong, or you need someone else’s help in resolving an issue please, please, please do your best to understand the issue, understand the scope of the issue and do your best to clearly state what you have done to resolve the issue.

Your unit test may smell if…….!

Derik Whittaker — Wed, 09 Sep 2009 17:28:30 GMT

If you find yourself using reflection in your unit test to push 'stub’ data into it your test just may smell. Now there are times (especially when dealing with legacy code) that you need use reflection to crack open a class to push/pull values but I would strongly suggest you consider the solutions I am going to suggest.

Utilizing the wrap method (see Working with Legacy Code) to accomplish your goal.

Lets assume you have the following class which you want to test:

  public class SomeClass 
  {
    private DateTime _lastVerified;
    private DateTime _lastActivated;
   }

Now one way to push data into these fields would be to do the following:

    [Test]
    public void IsTimeToActivateTrueLastActivatedTheDayBeforeCurrentTimeAfterActivationTimeTest()
    {
      SomeClass accessor = new SomeClass 

      Type type = SomeClass 

      FieldInfo field2 = type.GetField("_lastActivated", BindingFlags.Instance | BindingFlags.NonPublic);
      field2.SetValue(accessor, new DateTime(2008, 2, 29, 10, 5, 0));

      FieldInfo field3 = type.GetField("_lastVerified", BindingFlags.Instance | BindingFlags.NonPublic);
      field3.SetValue(accessor, new DateTime(2008, 3, 1, 10, 0, 0));
    
      DateTime currentDateTime = new DateTime(2008, 3, 1, 10, 10, 0);

      MethodInfo method = type.GetMethod("SomeMethod", BindingFlags.Instance | BindingFlags.NonPublic);
      object result = method.Invoke(accessor, new object[1] { currentDateTime });

      bool isTime = (bool)result;

      Assert.AreEqual(true, isTime);
      Assert.AreEqual(currentDateTime, field3.GetValue(accessor));
    }

Now this works, but if you do this over and over again you will kill yourself with reflection code.

Option 1) Create a subclass of your class and hide the reflection inside your subclass

public class MySubclassOfSomeClass : SomeClass
  {
    public void SetLastActivatedTime( DateTime value )
    {
    	// set the value via reflection here
    {
	
    public void SetLastVerifiedTime( DateTime value )
    {
    	// set the value via reflection here
    {
   }

The code above will still use reflection to set the value, but it will hide the usage of reflection from your unit test and will present a less noisy test to future developers

Option 2) Change the scope of the fields and subclass and extend

  public class SomeClass 
  {
    protected DateTime _lastVerified;
    protected DateTime _lastActivated;
   }

public class MySubclassOfSomeClass : SomeClass
  {
    public void SetLastActivatedTime( DateTime value )
    {
    	_lastActivated = value;
    {
	
    public void SetLastVerifiedTime( DateTime value )
    {
    	_lastVerified = value;
    {

If you change the scope of the fields to protected you could subclass the original class and do the same as option 1, but because you have access to the fields via inheritance there is no need to use reflection.

So, remember that tests are code to and if you feel pain writing test you may be doing it wrong.

Till next time,

Quantity is NOT a measure of Quality

Derik Whittaker — Fri, 21 Aug 2009 14:08:15 GMT

Today I was asked what I thought about asking each of our feature teams to report the total number of new unit tests created during their iteration. My knee-jerk reaction was to ask the person WTF were they thinking. However, my better sense (yea, I have a little common sense) kicked in.

Before I started to explain my point of view, I asked the person what the intent of this requirement was? Their reasons were below:

With this in place it will keep the developers inline in terms of knowing that creating tests is important
More tests == more coverage which SHOULD increase code quality
Simple measurement tool to track work items

Once all the points were stated, only then did I state my view.

Reason: With this in place it will keep the developers inline in terms of knowing that creating tests is important
I am ok with this being a goal as it is important for each developer to clearly understand what is expected of them when creating code. However, I would rather show them why creating unit tests should lead to better code with less bugs rather than force them to write tests or else.

We as a profession need to start taking the stance that we must convince or persuade developers, but rather show them why one way may be preferred or better.
Reason: More tests == more coverage which SHOULD increase code quality
In general principle I agree with this statement, however unit test count is NOT a good measure. Here is why:

I could spend 2-3 hours creating a single unit test that proves out a extremely critical path in code which adds great value or I can spend 2-3 hours created 20+ test that add little to no value. It is because of this single fact that count of tests (like lines of code count) can be a very, very useless measure.
Reason: Simple measurement tool to track work items
Well, I guess there is only one thing I could say for this one….When should I turn in my TPS reports

Anyway, If you are reading this and can take anything away, it should be this. Measurements are good, but make sure you are measuring the right metric. In terms of measuring code, lines of code and count of tests may not be the best measurement.

Till next time,

Wow, the hatred for ‘var’ lives on

Derik Whittaker — Fri, 14 Aug 2009 19:41:00 GMT

Here we are almost 2 full years since the var keyword was released to the wild, and only a few short months (I hope) till the next release of the .net framework and still the hatred for the var keyword lives on.

The other day I woke up to find the following rant waiting for me in an IM window:
[21:46] VarHatingDude: God I hate the var keyword
[21:46] VarHatingDude: worst thing ever invented
[21:47] VarHatingDude: deferred type is bullshit
[21:47] VarHatingDude: I want to see my types defined in my class
[21:47] VarHatingDude: before I mouse over them
[21:47] VarHatingDude: I will never use that piece of shit
[21:47] VarHatingDude: it's called lazy programming

At first i just kinda dismissed this rant and moved on. However, something about this made me think I should ponder the rant a bit more. After giving this a bit more thought here is what I have to say to the ‘var hatters’ out there.

RE: Differed Type: Is not a ‘differed type’, but instead it is an inferred typed variable. What does this mean? (from MSDN) Local variables can be given an inferred "type" of var instead of an explicit type. The var keyword instructs the compiler to infer the type of the variable from the expression on the right side of the initialization statement. The inferred type may be a built-in type, an anonymous type, a user-defined type, or a type defined in the .NET Framework class library.

What does this mean? Basically I can use var on the left hand side and the compiler will infer its type based on the INITIAL context it was used. Once its type has been inferred by the compiler it cannot be swapped or changed.
RE: Lazy Programming: I have to say I 100% disagree with this. To me using var is more about clean reading and more concise code. Take the following code
Person person = new Person();
The code above tells me in 3 places i am dealing with a person and this is a bit of overkill. If I use var as below I am not repeating myself over and over again:
var person = new Person();
Var allows for cleaner refactoring when you follow interface driven development. Many times I have changed the interface that I return (not simply doing a rename) from an object/method and as long as the new interface contains the same signature there is no need to recompile or recode my changes.

If you still hate var after 2+ years of it being out check out the follow blogs for other reasons to like/use it.

But like everything else in programming it all boils down to personal taste at the end of the day. However, if you do not like something that is cool, do your own thing your own way.

Tests are not ‘Tasks’ you put on a backlog…

Derik Whittaker — Tue, 28 Jul 2009 00:57:50 GMT

Today I had a conversation with our ‘scrum of scrum’ masters (we have 7 different scrum teams on our product team of 60+) and he asked me why someone would provide ‘developer tests’ as a task for the backlog?

Before I go any further, this is NOT a bait type of email, simply my opinion. If you do not buy into the testing (either TDD or test after) then you can disregard this post. But if you do buy into the testing concepts keep reading.

In order to gain a better understanding of the context I asked my SoS master for more background on this project and what they were doing. After a brief conversation I became very clear to me that this developer did not think of testing as part of his requirement of building out a feature, but rather as a stand alone deliverable that he needed to deliver at the end of the sprint.

I explained that all developers on our team need to stop thinking in this way and to start looking at tests as ‘first class citizens’ when creating code. I believe the exact statement I gave him was:

When developers are creating a feature, the unit tests which prove the feature as being valid is just as critical as the code which implements the feature.

Quite simply, IN MY OPINION if you buy into the testing concepts stop thinking about tests as a second class citizen and start thinking about them as part of your deliverable.

Till next time,

Throw away and rebuild or refactor from within

Derik Whittaker — Mon, 13 Jul 2009 19:39:19 GMT

The other day on Twitter there was a stream whether it is better to completely scrap an applications code base and start over, or refactor from within. Now I do want to state right now:

The information here is based on my experiences and is simply my opinion. I know this is almost on par with the average biblical debate so lets just agree to disagree now.

Anyway, now that I have put on the standard disclaimer lets continue on with the post. As I stated there was a debate on which was better, rewrite or refactor…..

Once upon a time I thought that without a doubt that rewriting that crap filled, unmanageable and unextendable code was the ONLY way to succeed. However, during my career I have come to the conclusion that rewriting was actually the wrong decision and refactor from within is the right one. Here are some of my thoughts as to why

Re-Writing
Pros:

You get to scrap that old code that smells.
You get to build a better, more maintainable architecture going forward.
You get to use the latest technologies and this is always the best thing.
We know the business better now, this will allow us to create a better, more flexible application

Cons:

Is the business going to actually stop innovating or changing long enough to let you completly rewrite the application? NO
If they are not going to stop moving forward this means there is going to be a maintance team doing this type of work. This means you are coding against a moving set of requirements that will change daily… FAIL
What makes you think that you can write it better the second time around? If you wrote unmaintable crap the first time why do you think you are better now (ok, assuming you did write it the first time).
More than likely you are simply going to pile on the latest tech because you can. Because you are an ego freak and the only way to write good code is to use new tech

Refactor from Within
Pros:

You have the ability to continue delivering new versions of the application with new features.
You actually increase your knowledge of what ‘crappy’ code looks like and how to fix it.
You can learn how to refactor your legacy code with minimal risk and learn how to do it a way that allows you to deliver new code

Cons:

This is NOT easy
This is NOT slow
There is always the thought that you will never actually be complete and that the refactor effort will be dropped at some point in the future. If this is true, rest assured that your application will be better off anyway.

Ok, there you have it, my list of pros/cons for each (this is not an all encompassing list, just some of my random thoughts). In my opinion the refactor is a better, safer choice. But this is not as sexy and takes a ton more effort and patience. However, I believe in the long run you will be better off.

Till next time,

You know you buy into Testing and Testabilty when you wrap a singleton simply to create an abstraction…

Derik Whittaker — Fri, 15 May 2009 22:27:58 GMT

I am a little bored so I thought I would write a nice fluent interface around the Performance Counter crap that is part of .net. I know, I know the world does not really need another Fluent Interface around something, but I am bored and this is keeping be busy while waiting for my flight.

Anyway, about 30 min into the coding session (going a bit slow as I am trying to use CodeRush/Refactor Pro in place of ReSharper) I needed to use the PerformanceCounterCategory class. The problem is this. Since this is a singleton isolating this during my tests is too painful, and because it is a singleton I cannot create an inheritance hierarchy to allow me to isolate it better. So, what did I do?

I created a wrapper around the singleton. By having this wrapper (and accompanying interface) I will be able to better isolate my tests and not actually create a shit load of categories and counters all the time.

Wrap Strategy Refactoring === FOR THE WIN

Singletons == FOR THE LOSS

Till next time,

Refactoring Project Structure is just as important as Refactoring Code

Derik Whittaker — Wed, 15 Apr 2009 19:27:54 GMT

We talk about how important it is to keep your code in working order, but no one ever really talks about keeping the container for your code in working order --- Your Project Solutions.

Per Wikipedia Refactoring code can be defined as:

Means improving it without changing its overall results, and is sometimes informally referred to as "cleaning it up". Refactoring neither fixes bug nor adds new functionality, though it might precede either activity

Lets take a look at some of the reasons why we refactor our code base (this list is NOT the be-all-end-all list)

Keep our code soft and flexible
We encounter new needs for our code and we refactor to allow for these changes
Improve the design of the code
Make the code design easier to understand

If you look at the above list you can see that you can apply many of these to the structure of your application. Let me provide a few examples

~~Keep our code soft and flexible~~ Keep your source tree/project tree flexible
We all have been on projects that just kept growing and growing. If you continue to let this happen eventually you will find yourself in a world of hurt. Take the time, prune your project solutions. Maybe it make sense to create multiple solutions… Either way keep it under control.
We encounter new needs for our ~~code~~ Structure and we refactor to allow for these changes
When our code starts to smell we refactor it. We may refactor the layout, the structure or how the pieces work. We should do the same for our code structure. If a given assembly is doing too much then break it down. If a given namespace has too much responsibility, create a new one.
Improve the design of the ~~code~~ source tree
See above :)
Make the ~~code design~~ source layout easier to understand
Making your project easier to navigate and find stuff is very, very important. We refactor code so the next guy can determine which way is up. We should refactor our project structure so the next guy knows how to find/add what is needed.

So the next time you think that refactoring only applies to your source code, stop and think again. The principles of refactoring (making changes to the content without changing the intent) can apply to many other aspects of our jobs.

Till next time,

Ivory tower policies or mandates are counter productive

Derik Whittaker — Thu, 19 Mar 2009 11:31:03 GMT

I am sure that most of you have heard the term ‘Ivory Tower Architect’ and most of have a mental image of what this means. To me, when I hear the team I think of a person or team of washed up, has been developers who are no longer capable of creating quality code so now they have been relegated to ‘mandating process and standards’.

What got me thinking about this was a comment to one of my recent posts about doing pull and compiles on your source code. In this post I speak about how your team/organization needs to be able to simply pull and compile all and any source in about 5 minutes. I also mention that the source should not depend on any 3rd party installs to simply compile, but if it MUST (and I know, I know there is always an exception to my rule) then you better have that installer inside your source tree along with a readme to explain to a new developer exactly WHAT must take place prior to compiling the code.

The comment that got me thinking started off great. The person made the statement that you should simply have to hit F5 to compile and run, and I guess in concept I agree with that, but I still think that you should be able to do a command line build without the IDE. But later in the comment the he goes on to say

Any 'special' libraries should be a part of the corporate image for a developers machine - a *real* shop isn't going to have umpteen different libraries anyway - they'll have a stack, and that stack will be the standard for every project.

Now, the first part of that statement about the corporate image I can agree with, however the second part is what got me all fired up. That part of the sentence just reeks of ivory tower architecture or mandates and I am always fearful of these types of mandates. Why am I fearful of these… well glad you asked. Mainly I don like these types of mandates for two reasons:

Lack of context
How could a group of people, or even a department within an development organization know the needs of each INDIVIDUAL team? I have seen and heard about the situations where a set of standards or frameworks (mostly home grown of course) were pushed down from above and were told, ‘these are the tools/frameworks that every team must use’. Can someone tell me how a member that is NOT on my team can possible know what tools/frameworks we need?

Stifles innovation
We are software professionals, we are paid a ton of money to create business value. How can we do this in a innovate way if we are told which tools/frameworks we can use. Not to mention, the pace of change in our industry is so fast and so often that if a team is told which tools they can use the chances are they will be years behind the 8-ball.

I understand that teams, even organizations what to have standards in place in terms of tools and practices. However, ever team has a unique need and each team needs to have the ability to make its own decision and forge its own path. Now do not get me wrong, when working on a big team there does need to be a standard set of tools (which logger to use, which testing framework, which IoC container, etc, etc) that will be used. However, this is the standard for THIS TEAM ONLY, and the standard was decided on by THIS TEAM. The distinction here may be subtle to some, but is great to me. By allowing each team to make their own decisions, they are better able to asses their needs and create better software.

Let software developers do what they do.. Create Business Value through solving business problems. Only way this can happen is if each team has the flexibility to make its own decisions.

Till next time,