Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Ivory tower policies or mandates are counter productive

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,


Posted 03-19-2009 6:31 AM by Derik Whittaker
Filed under: ,

[Advertisement]

Comments

Michael D. Hall wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 10:55 AM

I think there's a big picture issue here. When you have teams using everything under the sun, one team is using NH another SubSonic, another using a home-baked solution for database access. One is using log4net and another NLog. Then add in some specialty libraries that they picked up along the way. You have a problem in the long run. Maintenance, cross-training, resource replacement all will be very difficult for the company long term. How can you easily reorganize your teams if they are using extremely different toolsets and concepts? Heck, even language standardization. Basically what I'm trying to get at is that a standardized toolset isn't always a bad thing. We sometimes have to remember that when we are being paid to do a job we sometimes have to comply with the laws of the land. Sometimes I don't like it, and you know that I am somebody that will squawk if I can't get my tool of choice. I'm just saying that there's a flipside to the issue that isn't just about command & control.

Derik Whittaker wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 10:59 AM

@Mike,

I would agree 100% if we are talking about people on the same project/product.  But most shops (mine included) have about 20 products that range from web to client/server to mobile.  

Saying that EVERY one of them MUST use the same tools is crazy.  They all have unique needs.

Michael D. Hall wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 11:02 AM

The brutal truth, is that we are not all "professionals" in the implied definition of the word. Not all developers are as willing or able to expand their repertoire as you and your colleagues are. And most of the senior members aren't really used to working with your caliber of development and skillset. That might sound snarky, but it truly isn't. If I go into a new company and they are even using VSS I'm usually floored. That's just the way it has been in my experience. But the senior developers who set up these policies are usually developers like you or I who've been fighting the battle for too long and are just wore out from explaining themselves over and over and getting constant pushback. So when they get into a position of authority they lay down the law. Along comes a rockstar and they don't exactly know how to react except to use the approach they've used for years. Dogma. Just my opinion.

Michael D. Hall wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 11:05 AM

@Derik Maybe. There may be a standard stack but that doesn't mean you have to use all of it. Back when I was working for my father in his truck shop we had a huge toolbox full of tools. All work was done from that toolbox from fixing the roof to repairing the vehicles. We didn't just use the same hammer for everything, we had several hammers for different jobs. One standard toolset isn't entirely an evil thing.

Andrew wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 11:52 AM

I think you taking what was said a bit too literal.  That, or you were irked by the "a *real* shop" line because it smacks of elitism (which it does).

If it read something like:

"A good software shop isn't going to have umpteen different libraries anyway - they'll have a limited set of libraries to choose from for every project."

or something to that effect, I don't think you'd take issue with it.

As Michael pointed out, consistency within a development department is so important because more often than not the person maintaining a product is not the one who built it.

Derik Whittaker wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 11:58 AM

@Andrew,

Admittedly i just took this as a chance to rant a bit on this topic :)

Donn Felker wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 12:09 PM

I could not have put it better myself. Too bad people will always think "their way" is the best way and will still follow their ivory tower mentality.

Andrew wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 12:25 PM

Derik,

I do think you have a point, I'm pretty sure we've all worked with the kind of person who always uses qualifying statements like "I have 20 years experience!" when they are asked questions about their horrible code. :)

Bill Sorensen wrote re: Ivory tower policies or mandates are counter productive
on 03-19-2009 1:09 PM

I agree with Mr. Hall. It all depends on how your organization defines "team".

We have an in-house applications development department that primarily deals in WinForms, a web development department, and a bioinformatics department. Each determines and uses its own set of tools. There is some lateral movement of developers, but generally one stays in one's own department.

Within a given department (like AppDev, where I work), there are multiple project teams operating at any given time. After a sprint, a developer may be assigned to another team. It would greatly increase training requirements if every team were allowed to pick their own persistence framework, logging framework, UI component toolkits, or even .NET language. Learning a new problem domain is enough of a challenge.

And then there's the additional challenge of supporting multiple frameworks in the field...

DotNetKicks.com wrote Ivory tower policies or mandates are counter productive
on 03-20-2009 2:19 AM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

igorbrejc.net » Fresh Catch For March 22nd wrote igorbrejc.net » Fresh Catch For March 22nd
on 03-22-2009 5:05 PM

Pingback from  igorbrejc.net » Fresh Catch For March 22nd

Justice wrote re: Ivory tower policies or mandates are counter productive
on 04-02-2009 7:56 PM

I agree with your post in part.  My general strategy has been to say for organizational consistency that there should be a pseudo-standard "stack" (e.g. let's not have everyone in the entire department have 15 different ways to solve data access).  That being said, every project has their own individual needs and thus should be capable of arguing cogently to justify why they would need to deviate (I had this experience in reverse several years ago when I was asked to justify why my $20M+ project was going to be using NHibernate vs. dataset-driven designs).  

As for "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."

You'd be surprised at how many developers spend more of their time whining about tool stacks vs. actually delivering real business value.  I'm not for mandating anything, but I also wouldn't want there to be a repetitive spiral on the team trying to repeatedly refresh/investigate new technologies at the expense of, you know, actually getting shit done.  And I've seen that sort of intellectual masturbation happen too many times, or on too many blogs, even!  ;)

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)