Stature Software

LinkedIn LION - Why?

August 11th, 2008 by Gregory Silvano Posted in Developers, LinkedIn | No Comments »

Have you ever noticed a LinkedIn profile that has “LION” or “L.I.O.N” or “Open Networker” in the name?  LION stands for LinkedIn Open Networker, and I’m not going to beat around the bush here: I just don’t get it.

LinkedIn is not a popularity contest.

What good are 500+ connections if you don’t actually know any of them?  Are you suddenly more important (more popular?  more profitable?) if you have 1,500 connections on LinkedIn?  The goal of networking is to build relationships with people, not to collect their email addresses and add another notch on your Rolodex tally.

Today I have 185 contacts in my LinkedIn profile, a number that may decrease in the near future.  I’m going to remove anybody whom I am not 100% comfortable calling and just saying hello.  If I have to call you, explain who I am and where I work, then honestly I don’t think there’s much reason to include you in my professional network.  And that’s what LinkedIn is supposed to be - a professional networking resource.

Here’s my LinkedIn Network Quality Test.  To be in my LinkedIn network (not that it’s an honor), a contact must fit this criteria:

1. I trust you.
2. I like you.
3. I have had more than one email or phone call with you at some point in our relationship.
4. I want to do business with you sometime in the future, if we don’t do business together already.

 

That’s it.  These four criteria embody the exact opposite of the LION philosophy, which is simply: if you have an internet connect and can type my email address, welcome to my network.

 Tags: LinkedIn, lion, open networker

Software Developer Productivity - The First Deliverable Dip

August 4th, 2008 by Gregory Silvano Posted in Developers, Software Development | 1 Comment »

I have a theory about the productivity of software developers, and I’m going to call it the First Deliverable Dip.

Software projects have certain phases, as do all projects.  We have conception, brainstorming, kickoff, development, QA, implementation, etc.  Being a programmer myself, I know the parts of the project I like best.  I like the brainstorming and the kickoff, but by the time implementation rolls around I’m pretty much done with whatever it is I’m writing.  I’m sure many developers feel the same.

Now that I’m in management, I want to get a better understanding of developer productivity.  This matters a great deal to me since unproductive developers affect my bottom line.  With 52 software developers at Stature, if all our developers have just one unproductive day it equates to over two months of unproductive business days.

Wow, OK - I just scared myself with that statistic.  The bottom line is that it’s important for Stature to keep its developers productive, motivated, and happy.  Happy developers are productive developers, and productive developers pay my mortgage.

Alright, enough intro.  Here’s the meat of my argument:

I believe software development productivity dips immediately after the first deliverable, when the client first sees a functional version (or subset) of the product.

The “client” is whoever will be using the software.  For Stature, it really is a client.  But for an internal developer, your client is probably a business user at your company.

Here’s what happens:

1. The client works with the development team to design the product.  There are meetings, brainstorming sessions, and eventually some sort of spec.
2. The development team disappears for a period of time.  At least a few weeks if it’s a decent sized project.
3. The development team codes like mad and is highly motivated and productive.
4. The development team prepares for the first deliverable, probably a subset of functionality or a functional wireframe version of the application.
5. The client views the first deliverable.  It is probably presented to the client by the development team, and the client is walked through the functionality and progress to date.
6. The meeting ends.

 

Soon thereafter, developer productivity starts to dip.  Why?

1. This was the first time the client actually felt the application.  Specs are one thing, mockups are another, but to actually use the application is entirely different.  Now that the client has used the product, the first set of changes are about to come.  These changes will come soon - if not at the meeting itself (in the form of “hey, can we…” type questions), then within days afterwards.
2. Once the developers receive the changes, they need to make unanticipated changes to their code.  Even worse, immediately after the meeting the developers are probably working on the very parts of the product that are going to be changed by the client.

 

It is during this period that overall productivity dips.  The project isn’t moving forward with the same energy and productivity as before.  Sometimes the developers start to get that “Us vs Them” mentality, where the they think the business users are neophytes who don’t understand software development (hint: business users don’t understand software development; nor should they).  The developers are forced to abandon some of the cool parts of the code (hey, they spent 3 days getting that treeview just right!) and resent throwing the code away.

This productivity dip is inevitable but the affects can be minimized:

1. Warn the developers that the client is going to do this.  Just knowing it’s coming can make it easier to deal with it.
2. Immediately after Milestone 1, we often have the developers work on tertiary parts of the product.  Things like reports, admin-screens, password-reminder screens, etc.  We have them work on the parts of the application that need to be written eventually (but are often left to the end) and don’t require much client input.  While they’re working on this functionality, the client has the time to thoroughly (and thoughtfully) review the first deliverable and provide feedback.  In the meantime, at least the developers aren’t continuing to code something that may be altered by the changes being written up by the client.

 

The First Deliverable Dip is a real thing.  It can last for days or weeks depending on the changes requested by the client.  Normally the changes are more pronounced when it’s a brand new project that only existed on paper before the first deliverable.  In those projects, it’s really hard for the clients (users) to know how the product is going to work until they get time to play with it.  But with a little planning and lots of patience, it’s a part of the development cycle that can be managed.

And honestly, I don’t blame the clients one bit.  Imagine designing a car on paper.  Do you really think when that car is delivered from the manufacturer, it would feel exactly like you anticipated?  No way.  The radio controls may be a little awkward now that you actually get to use them.  The seats may be a little uncomfortable.  There may be a blind spot.  It’s the same with software projects - you just don’t know how it’s going to feel until you use the product.  That’s life.  Just plan for the changes and everybody wins.

 Tags: deliverable, milestone, productivity, software developer

Cuil Search Engine

July 28th, 2008 by Gregory Silvano Posted in Technology | No Comments »

Today I read about Cuil for the first time.  It’s getting quite a bit of press, probably thanks to the prominent link on the Drudge Report today.

So I gave Cuil the same test I give every search engine - and it failed miserably.

1. A search for Gregory Silvano didn’t pull up anything special.  And if the first page doesn’t include my LinkedIn account, then sorry - it’s not a very good search engine.
2. A search for Stature Software returned nothing worthwhile.  We’re not a hugely important site on the web, and that’s exactly the point.  Most sites aren’t hugely important on the web and that’s why I need the search engine.  If you search for Stature Software on Yahoo, Google, or MSN you’ll get our web site at least.
3. It was slow.  Too slow.

 

I’m no Google lover by any stretch, but Google wins this fight.

 Tags: cuil, google, msn, search engine, yahoo

The Most Important Project Manager Skill?

July 24th, 2008 by Gregory Silvano Posted in Software Development | 1 Comment »

For the past few days, I’ve been working closely with Stature’s newest hire, Mike Bykow.  He’s a Project Manager at Stature and is handling several projects for us.

As I was driving him back to South Station yesterday, I listed all the things I think are important for a Project Manager at Stature (or anywhere, for that matter).  I mentioned the obvious things, like: communicating with the clients, making sure you understand every facet of the application, keep in touch with the developers frequently so you’re on top of schedule slips, etc.

But then I told him something that, the more I expanded on the idea, I realized it was the most important skill of all.  I told him he needs to learn to finish the project.

Software projects can go on forever.  Literally.  They can be tweaked and tweaked for months on end.  This is beneficial to no one, but especially for a company like Stature.  We need to finish projects to maintain profit since nearly all of our projects are fixed-price and we don’t issue change orders (see our 3 Guarantees).  So to have a project run over by a month is a big deal for us since we can’t recoup those costs.  Software Projects don’t end naturally - they need to told to end. 

If I were a Project Manager, I’d want to be known as The Closer.  The guy who wraps up his projects on time, on budget, and to spec.  If another project is running past schedule, I want to be the guy they bring in to restore order and get the project done.

In the coming weeks, I want to expand on this topic and discuss the tricks we’ve learned over the years that allow us to close a project.  It’s something you learn through experience and observation, and I think with just a few high-level rules any Project Manager can become The Closer.

 Tags: project management

New Project: Online Store

July 18th, 2008 by Gregory Silvano Posted in Stature Projects | No Comments »

We started a new project this week for a publishing company who needed a very customized online store for their products.

We started down the path of DotNetNuke and some commerce modules, but in the end it was easier to just code it ourselves.  Although very powerful, the DNN commerce modules were just too limiting.

We’re using C#, ASP.NET, and SQL Server 2005.  They already have an Authorize.net account, so the credit card processing is very easy through their API.  The store supports features such as pricing matrix, related products, out-of-stock messages, shipping, tax, filtering the products by the registered user’s state of licensing, and full integration into their CRM system.

 Tags: Authorize.net, CRM, ecommerce, online store