Um, progress?

“Progress” is changing code that results in a new error message.

Curse those bugs

I can honestly say that my day as a software developer is going FAR better than some others out there.

Source: https://news.google.com

Advertisement

Account, Development, and the Tension Between

Debbie: "You sold what?!"

Steve: "What do you mean you can’t build that?!"

Debbie: "You told the client we’d have it ready when?!"

Steve: "You can’t spend three weeks polishing the code – we need to go out tomorrow!"

If you are a developer or an account person in the software/digital marketing industry for any length of time, you will probably encounter or make some variation of the above statements.  What I’ve come to realize is that there is a fundamental tension between the account person – let’s call him Steve – and the development person – let’s call her Debbie. 

The typical Debbie can wax poetic about the ridiculous deadlines, insane requirements, and unbelievable client requests that account commits her to.  The typical Steve can do the same for the infuriatingly obstinate and short-sighted developers that he has to drag kicking and screaming through a project.  So this tension is bad, and we need to find ways to reduce and even eliminate it.  Right?

Wrong.

This tension serves an absolutely vital purpose in a company.  It mustn’t be banned – it just needs to be balanced.  To do that, we need communication.  Let’s say that our two personas, Steve and Debbie, actually go into business together and create a company called Spelltronix*.  We’re going to explore the tension between the two of them in three scenarios.

 

Scenario 1
Let’s say that Steve committed Spelltronix to building a new web site that does X, Y, and Z for A dollars in B weeks, without ever consulting Debbie.  Debbie is a more than a little offended when he brings back those details and says "Here you go".  Here are just a few problems Debbie might find with this scenario:

1. Feature X is not feasible in the time allotted.
2. Feature Y will cost more to develop than what you negotiated, or will require the client to buy licenses for third-party software for more than what you negotiated.
3. I’m already working on Projects J and K, and therefore can’t start on this new one for another month, so the deadline is unreasonable.
4. I have no expertise in this domain, so Feature Z is beyond me right now.  I’ll need to attend some classes, or do some extra reading to get up to speed, and that will require additional time.

My guess is Debbie won’t enjoy working with Steve for very long if he keeps committing them to projects like this.

 

Scenario 2
Now let’s say that Debbie agreed to build a system with requirements X, Y, and Z, for A dollars in B weeks.  Steve gets the agreement signed by the client, and Debbie goes off and starts work on the new system.  Steve comes back after B weeks to see how things have gone.  Debbie reports:

1. Feature X is complete, Y is mostly done but buggy, and Z has not yet been started.
2. Debbie spent a lot more time trying out new third-party libraries for feature Y, finding several that did the job, but most weren’t "neat and clean" in her opinion.
3. She didn’t have any domain expertise with Feature Z, so she has been doing a lot of reading about it, trying to get up to speed.  That’s part of the reason why she hasn’t started it yet.
4. She’s logged a lot of overtime, and spent a lot in licensing on those third party libraries, charging all of it back to the client.  As a result, costs on this project have already exceeded the A dollars that they bid, and that doesn’t include the time needed to finish the unstarted Feature Z.
5. It will take another 2 weeks to finish up work on Feature Y, and then start and finish feature Z.

My guess is Steve won’t enjoy working with Debbie for very long if she keeps executing projects like this.

In both of these scenarios, the tension is very one-sided.  There was no balance.  What would help avoid these?  Project Managers, you say?  Maybe, but when you boil the role of a PM down, what does he or she really do on a project?  And no, the answer is not "Gantt charts".  A PM’s primary job function is make sure all of the stakeholders in a project have the information they need, when they need it, in order to keep the project on track, on budget, etc.  In a small shop like Spelltronix, I wouldn’t start by adding a PM.  I would start by getting Steve and Debbie to ACTUALLY TALK TO EACH OTHER! 

 

Scenario 3
Steve and Debbie visit a new prospective client together.  They spend a couple of hours gathering information about the client’s needs, asking questions about the new proposed system, and finding out where the client is headed in the future.  They return to their office, and spend the rest of the afternoon pouring over their notes individually.  They spend much of the next two days discussing the project together, where several questions consume the conversation:

1. Do we think we understand all of the major requirements well enough to bid on this?
2. How much do we think this will cost us to do?
3. Do we have the necessary expertise?
4. Can we build this in the timeframes that the client is requesting?
5. Can we hire or contract pieces of this out?
6. What about Projects J and K – can we wrap those up before we start this one, or even run all three concurrently for a period of time without getting into trouble?

They work up the proposal together, and are eventually awarded the work.  They bring on two contractors for the specific piece of the project that Debbie is not familiar with.  Debbie is able to manage the contractors while she wraps up her other two projects, and then joins them full-bore when those wind down.  Steve, Debbie, and the contractors hold daily meetings to coordinate efforts.  Debbie evaluates several third party libraries to use for one of the features, and while she doesn’t like how any of them look, the team all agrees that several will do the job.  To meet the deadline she selects the one she feels is the best of the bunch and allows them to keep things moving along.  The contractors are released when their piece is finished, and Debbie wraps up Phase 1 on time, without any major surprises.

In the first scenario, Steve is committing their company to things that Debbie can’t do for one reason or another, but if he had waited and talked through those proposed commitments with Debbie, they could come up with more sensible ones to propose. 

In the second scenario, Debbie got overzealous with her approach with the design and implementation of the solution, and needed to be reined in.  She also needed to say she needed help sooner on the feature that she had no expertise in.  Having regular touch points between Steve and Debbie (weekly-, or even daily stand-ups) would have kept her on task, and kept the project moving forward.

In both cases, more communication was needed between Steve and Debbie.  The lack of communication caused the tension between the two sides of the company to be one-sided, and therefore unbalanced.  That led to unbalanced results.

However, when the two sides communicated as in Scenario 3, the tension was balanced.  Steve and Debbie had to contend with all of the same issues in the third scenario – with all of the same tension.  They undoubtedly had to discuss and go back and forth on the issues.  Debbie couldn’t magically conjure up more time in a day to get her existing work done AND take on this new project.  Steve couldn’t magically convince the client to cut out the feature that Debbie wasn’t familiar with.  But because they were communicating, that tension was balanced, and they were able to work through those issues, and arrived at a much better result.

Is communication and balancing tension between someone like Steve and someone like Debbie going to ensure unicorns and rainbows at the end of the project?  Of course not.  But if Steve and Debbie DON’T communicate, the tension between them will be unbalanced from the start, which will make it more likely that dumb luck and 11th-hour heroics will be required to prevent their project from going off the rails.  And that’s no way to run a project, a team, or a company.

 

*I just made this up.  Any resemblance to a real company, living or dead, is purely coincidental.

How to start a new project

“A good beginning makes a good end.” – English Proverb

When I get the opportunity to start a new project, the first thing I do is create just enough of the application that I can build it and get something tangible on the other side (for a web site that’s usually the Default page, the Web.config, and the compiled assembly; for a desktop/console app that’s usually just the executable itself).   The second thing is I’ll establish the build process.  A “build” for me means pulling source down from source control, compiling, running unit tests, packaging and deploying.  CruiseControl.NET and NAnt are my two tools of choice, but there are many others.  Putting the build process in place now has several advantages.

First, it means that the build process becomes reliable and invisible, right from the beginning.  I want to be able to add a new page to my web site (for example) and know that that page will be correctly and completely included in the package that I send to the client.  Oh yeah, and I want to not have to think about it every time.

Second, putting the build process in place when the application is in its infancy allows me to grow it with the application.  That means I can keep the application and the process that builds it in sync, and greatly reduce the risk that I’ll forget to include something in the final package.  There’s nothing more frustrating than spending weeks or months building a great web site or app, only to have it break in production because you forgot to deploy some critical file added back on Day 3.  It’s like jumping over the Grand Canyon and making it 98% of the way – the end is close, but it won’t be pretty.

Third, having the build process in place from the beginning makes it very easy and painless to do a rebuild.  If I have it working in Development and now I need to go to Stage, no problem – add Stage as a new possible destination and force a build.  If I need to set up a new copy of Stage because the client wants to review it this afternoon, no problem – adjust the build script to the new destination path and force a build.  If something doesn’t look right in the Development environment, no problem – just blow it away and force a build.

In the end, it’s all about where you start that makes the difference between success and a very late night.