Sorry, I just had to post these.  Too Funny!

Start getting control

My first article in this series I outlined twelve points that I generally find to be true in respects to a start-up company.  While moving from start-up mode to corporate mode there will be some pain points.  So let’s talk about things you can do to start making an immediate impact. 

There are two things that will have immediate impacts on your business during the transition.  The first is attrition.  Folks who started working for the start-up from day one will begin to feel like the power they once had is being taken away.  These folks could make decisions on a whim.  They know where everything is, because they put it there!  At the time this was appropriate.  Everything was about getting the business going.  Now, that you’re moving to a corporate or enterprise mentality these decisions can have dire impacts on the companies operations. 

The second major impact is the inevitable lack of documentation.  So what type of documentation are we talking about?  I mean everything.  How many people in your organization know what server has what software installed?  How about dependencies?  License agreements?  What about all of the small applications that were built to bridge the gap?  Who built those?  Chances are there are only a select few people in your organization that can answer these question.  And I bet there are some surprises. 

So here’s the dilemma.  You have a lot of information in the hands of a few folks that are beginning to feel disenfranchised.  No matter what you do these folks will eventually leave.  Your first plan of action is to try to harness this mind share as soon as possible. 

The Tool

A cheap and very effective way of doing this is to setup a Wiki.  I’m not kidding.  I have found this to be very effective tool for documentation.  It’s what Wiki’s were made for!  IT folks have a tendency to want to brag through documentation.  It’s natural that they will run with this.  To help the process along appoint a Wiki admin.  Setup some templates for people to follow.  I’ve seen templates for Server documentation, applications (including release notes), Product roadmaps, IM accounts, people, etc.  Believe me, consistent presentation of information will go a long way towards adoption.  Have your Wiki admin setup a front page to highlight ‘good and new documentation’ as well as a ‘most wanted’ list.  Finally give it a name.  At the company I currently work for we call it ‘TWIKI’ as in Tech Wiki. We even branded it with its own logo.   Interesting enough some of our largest user base is not in IT.  The business and sales teams use it on a regular basis to get the most up-to-date information.

This strategy will solve a few issues:  Attrition and the loss of organization knowledge, documentation issues, as well as a great communication platform between your engineering department and the rest of the business.

During Part 3 I’ll be discussing the importance of asset management and how not doing so can really cost you.

Let’s talk about code metrics for a second.  It’s not something that is typically tracked by development teams, but here’s why you should.  Gathering code metrics can give you valuable insight into the testability and structure of your code.  By monitoring a few key metrics you can spot places where your code may need to be refactored.

Tools:

Let’s start with a free tool named Source Monitor.  There are lots of tools out there, but this one will do the job.  Essentially what you do is point the tool at a directory containing your source and the tool extracts all kinds of information for you.  I’ll let you go through all the bells and whistles on your own time.

The Metrics:

I personally like the Kiviat graph provided by Source Monitor because it displays a quick overview where your metrics are compared to your thresholds (These are configurable in the Options section). 

So what you say?  Let’s take a look at some of these metrics.  As you can see my test project’s metric for Max Complexity is outside of my threshold of 2-8.  So what’s a Max Complexity?  It measures the amount of code execution paths per method.  That’s right… All the If’s, Else’s, For each loops, etc.  Judging by how far it’s out of bounds there are probably some methods I need to consider refactoring to reduce the paths and make my code more testable!  Easy.  The same with Max Depth.  It measures the maximum block level depth.  clearly I’m outside the bounds I set.  The tool is configurable but you get the idea.

Still wondering so what?  I would take a look at this book review of the ThoughtWorks Anthology:

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.
2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.
3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.
4. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation.
5. Don’t abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you’re likely to spend more time thinking about its name. And you’ll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship().
6. Keep entities small. This means no more than 50 lines per class and no more than 10 classes per package. The 50 lines per class constraint is crucial. Not only does it force concision and keep classes focused, but it means most classes can fit on a single screen in any editor/IDE.
7. Don’t use any classes with more than two instance variables. This is perhaps the hardest constraint. Bay’s point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class.
8. Use first-class collections. In other words, any class that contains a collection should contain no other member variables. The idea is an extension of primitive obsession. If you need a class that’s a subsumes the collection, then write it that way.
9. Don’t use setters, getters, or properties. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim “tell, don’t ask.”

I’m not sure about you, but I’m always looking to do better OO. :)

 
I once heard a saying that you don’t know where you are if you don’t know where you’ve been.   I’ve had the pleasure  of working for several start-ups as well as some established companies through out my career.  I’ve always been fascinated by the transition companies go through when moving from start-up mode to corporate operations.  No where is the change more evident than in IT.  This is a tough transition plagued by pitfalls and hard lessons.  Hopefully, by you reading this post and the ones to follow, you can gain some insight as well as avoid some of these pitfalls should you have the fortunate experience of making it out of start-up mode.

This post is the first part of a series I’ll be posting in the next few months addressing this phenomenon.  Many of these lessons are from first hand experience.  However, like I said I’m fascinated by the process and I would love to hear your stories be them successful or otherwise. 

Characteristics

What is start-up mode vs corporate operations?  We will need a definition.  My view of a start-up is a company that is just trying to establish itself.  This is a loaded definition because there are many facets to an established company.   The first is that a company must establish a product or service.  No doubt obvious and tangible.  But we must also consider the non-tangible, things like culture and brand recognition.

So what does a start-up look like from an IT perspective?  The truth is that it can be in a variety of states, but here are twelve points I typically find to be true: 

1. No centralized management of assets
2. Data center sprawl
3. Release Management in disarray
4. Lack of code standards or code reviews
5. Inconsistent SDLC processes
6. Missing Architecture strategy
7. Lax security policy
8. Missing disaster recovery plan
9. Lack of code documentation
10. Lots of ‘small apps’ to bridge a gap
11. Missing or lacking quality control points
12. Inconsistent help desk operations

These points all sound bad, but remember, the goal of a start-up is to make it to a point where these issues can be addressed.  Implementing a coherent SDLC process is useless if you don’t have a product or customers to serve.

So what makes corporate operations different than start-up mode?  I’m sure most of you reading this can think of examples where the corporation you work for either isn’t doing all of these activities or struggles with these activities.  The main difference is that the corporation you are working for is probably doing some of these or is working towards these activities.  A start-up has to begin with a clean slate.  Improving one of the twelve activities is a different animal than starting from scratch.  Especially when you consider the ‘culture’.  Remember you are moving away from the mind set of ‘just get it out’ to ‘let’s do it better’.  For many folks that were involved in the start-up from the beginning this is a tough pill to swallow.  Attrition will happen, you will loose rock stars and gain new ones.  For this reason alone it’s good to start implementing some of these controls as soon as possible.

During Part 2 of this series I’ll begin to discuss which of the twelve points above are the least painful to implement, and why they are important.  Please check back for more next week!

I’ve recently found a site named dzone.com.  Dzone is a lot like Digg.com where you can vote articles up or down based on its merits.  What makes Dzone.com different is that it’s Technologist centric but not biased towards any one technology.  There are articles from Enterprise Architects, UX Designers, Developers, and IT Management (links are sprinkled with all kinds of views).  I have found more interesting articles here than anywhere else. 

It’s a great community and I would highly recommend that any serious technologist book mark this site, read it often, and participate in the voting and discussions.  Not to mention it’s a well designed site.  The Ajax scrolling feature is hot!