Tag Archives: Managing

This is harder than it sounds.  I’m thinking about this topic because I’m the manager of a software product team.  I’m responsible for the product’s health and speedy delivery.  Because of that, I need to steer the team in the direction with the shortest path to the finish line.  Some of the things I’m focusing on are as follows:

Part 1: Eliminate Waste

I think there is merit in the “Lean” notion of software development.  Earlier in my career, I worked for Dell, Inc. as a software developer.  At the time I was pretty pleased to be working for the worlds largest computer manufacturer, but being there taught me a lot about waste and how to indulge in it.  I’m sure other large companies have these problems, but I observed so much waste, it hurt my morale.  All the talk about “work smarter, not harder” was hard to apply inside the work culture.  Mechanical tasks were being done by humans, and manual tasks often had to be repeated several times.  I remember spending days working on items that our business partners were never able to benefit from.

Logically, if we eliminate waste, all that will be left will be tactical and strategic tasks that have a direct impact on the business.  In software, what things could be waste?  Manual tasks:  database migrations, build delivery, pre-production software installations, manual refactoring (without the aid of a smart IDE), typing code instead of generating it, reporting status, slow communication, etc.

Database migration

This screams to be automated.  Perhaps there are some testing databases with realistic data preloaded.  Suppose these are used for reviewing an incremental release to stakeholders.  After the stakeholders are finished reviewing the current build, they will have changed the data in the database, and over time it won’t be so realistic.  For every build review, it’d be nice to have that realistic database back, so we restore it from backup, detach/attach, etc to get a fresh database for the stakeholders.  The key is to not spend human time on such a task.  This task is repeated every 1 to 2 weeks.  Human time is often the most expensive part of software development.  A quick batch script could easily automate the refresh of this database and free up human time for more critical thinking.

Build delivery

To demonstrate the incremental build, how do we install it?  Who builds it?  Does a “build master” build it in release mode?  Why should a human have anything to do with this mundane task.  CCNet and NAnt are more than capable of building and delivery the software package in a zip file.  Extract the zip file on the demo machine and run.  Again, this type of activity is not worthy of human attention.  Make the machine work. 

Pre-production software installations

All software is different.  Some have client components, server components, distributed components.  Mature software teams have environments set up for testing.  These environments are for testing an incremental build.  How does the incremental build get installed?  If there are multiple servers with distributed services, who sets it all up.  I don’t mean to sound like a broken record, but this task doesn’t require critical thinking.  Leave it to the machine to deploy to the testing environment.  The task that requires some thought is putting together the deployment script for the machine to run.  Invest some time in an install script using NAnt, MSBuild or good old DOS commands, and then you can turn it over to a machine to reliably perform over and over again.  In fact, would your testers appreciate a command to run any time they are ready for the next build?  Why not have it in 2 minutes rather than scheduling an environment refresh?

Manual refactoring

If you’ve read any of the other posts on my blog, you see that I’m a fan of tools.  I especially love Resharper because of all the time it saves me.  I remember not using it to.  I remember renaming a public property and then using CTRL+SHIFT+F to do a solution string search for the property.  For a popular property, this might take a few minutes.  With Resharper, it is sub-second.  That’s right.  No more search and replace.  Looking back, why did it take me so long to demand a better tool?  What about pulling a method from a concrete class up to an interface?  I’d never do it manually now when a tool can do it with a few keystrokes.  Again, it’s trading human time for cheaper (and faster) machine time. 

Typing code instead of generating it

I’m not talking about software generators.  I’m talking about micro-generation.  If I need a class with 3 fields, a constructor, and some properties, I can type every character, and I have in the past.  It is much quicker to allow a tool to do it for me.  Resharper as well as CodeRush make use of micro-generation to throw in standard constructors, properties, and they do standard code completion too.  In fact, I let Resharper name my variables for me.  It guesses so well that I have very descriptive variable names after only hitting 4 keys.

Reporting status

This can take quite a bit of time.  Often a stakeholder or project manager interrupts developers to inquire on status.  There is no need for this.  The software team already tracks status somewhere, whether it be in an excel spreadsheet, on a whiteboard or a storywall.  Wherever status is available, just make it more broadly available.  Welcome your stakeholders to take frequent looks at it.  There is no need for in-person interruption just for status. 

Slow communication

Manual gather of status is a form of slow communication.  I’ll throw out a tip on how to slow down communication if it happens too quickly at your company. </tongueInCheek> Give every member of the software team their own offices and make sure all conference rooms are scarce resources and hard to book.  In fact, location members of the software team in different parts of the building, or maybe in a different time zone.  That should slow down communication sufficiently.  Slow communication will slow the production of software.  This is a form of waste.  Waiting for the answer to a question is wasteful.  To eliminate this, locate all members of the team in the same room without physical barriers.  Product managers too.  This will foster instant communication.

Conclusion

Eliminating waste is key to a productive team.  Identifying waste takes some critical thought, though.  Some teams are so busy with wasteful tasks that they can’t slow down to think about remedies.

[tags: software, lean, eliminatewaste, tools, productivity]

James Shore is taking lessons learned and teaming up to write a book called “The Art of Agile Development”.  He’s posting sections on his website for review.  You can read a section and post what you think to his Yahoo group.  I’ve followed James’ blog for quite a while, and his normal diary has been very useful to me.  He has a great deal of insight into how to manage a software team.

I’d recommend this reading for anyone involved in a software project.

This is a planned follow-on to my first post on hiring.  In my first post, I talked about the general process I like to go through when hiring a new programmer.  Of course, you can bet that this is continually evolving based on what works and what doesn’t.  So far, this is working very well.

When hiring, you obviously want to ask all kinds of questions, but I have to admit, I agree with a popular mantra that many speak about, including Joel Spolsky:  “Smart people who get things done.”  Smarts isn’t everything.  Take me, for example.  I know so many people who are smarter than me, hands down, but I make up for it with drive and persistence. 🙂   “Getting things done” isn’t everything either, because I’ve known my fair share of those people as well.  Sure, the system works (now), but with the “smart” in there, it could be a big jumbled mess that’s a maintenance nightmare.  I believe the two go together.

How the heck do I determine if the candidate is a good mix of the two?  Ha ha.  No easy answer there either.  I have to use my own experience to weight everything the candidate has to offer.  Some reference checks can help to determine the mix.  Some phone screen questions can contribute as well.  For me, I think the coding assignment can help determining the “smart” part.  I’m not fond of assignments like “create a Roman number converter” because that mostly tests procedural programming skills.  While there is value in that as well, I’ve preferred to ask them to do a little something with a technology that they have no experience in.  I leave it open-ended.  Using every available resource, this is downright easy for a smart person, and it should be because I need to respect their time.  It has the potential, though, of saving an interview for a candidate we wouldn’t hire.

Getting things done:  I think questions can bring this out.  It seems like it almost a mentality of getting things done as opposed to talking about getting things done.  Stories of past projects can help with this factor.

What else is pertinent in a candidate I’m looking for?  Ignorance of something!  What?  Did I read that correctly?  Yes.  If there is something the candidate doesn’t know, he is human.  If the candidate is so well-versed in everything, then he’s kidding himself.  Very few people are like that, and they certainly don’t have to interview.  Real people don’t know things.  Real people are constantly learning.  Someone who is slow to admit ignorance might be hard to work with.  From personal experience, the more I learn the more I realize how much I have to learn.  Does that scare anyone else but me?  I hope so, but it’s real.  Remember the teenager syndrome?  Teenagers know everything!  In fact, they know little, but are foolish enough to think they know everything.  Wise folks reject this notion as time progresses.  I’m impressed with someone who can talk about the things he doesn’t know.  This shows me that he can recognize gaps in knowledge that need to be filled.

Continual learning is another biggie for me.  Someone who is constantly learning impresses me.  I ask what technical things the candidate is reading/studying.  Answers that include books, magazines, etc are all good.  Nowadays, podcasts are in that boat too.  If a candidate struggles and finally comes up with an article they ran across “last week”, I get suspicious and follow up on the topic.

There are so many different techniques to find good people, and there is no way I can know them all, but I continue to learn. 🙂

[tags: hiring, technical, candidates, recruiting, interview, interviewing, managing, programmer]

With unemployment at essentially ZERO these days, it’s hard finding the best people, especially skilled knowledge workers like programmers.  Every company needs programmers, so the good ones who happen to be looking are few and far between.  By contrast, the mediocre to poor programmers are abundant and available.  Wading through the duds to find the right guy can be a daunting task. 

In-person interviewing is the most expensive part of searching for new employees.  It requires real time from the people in the department.  Each time a candidate is turned away because of an interview, the company has lost time and money.  The trick is to keep the bad candidate from making it to the in-person interview.  I’ve recently employed a few techniques to minimize time spent by my team on interviews.  My goal was to bring a candidate to interview only if I felt we would be making an offer.  Here are the things to do to weed out the folks who are unlikely to make it to the offer stage:

• Do a technical phone screen on every candidate.  Ask basic questions about levels of experience on required technologies and 3rd party libraries.  For instance, if your team uses 3rd party tools like CruiseControl.Net, Resharper, NAnt, NUnit, SVN, NHibernate, Rhino Mocks, etc, then it’s a plus if a candidate has used some of them.  This phone call should also ensure that you aren’t wasting each others’ time.  Make sure the candidate is interested in the kind of team you are running.
• Given them a “take home test”.  Make the questions appropriate for the technology (no insulting trivia).  Good questions are ones that a good programmer could answer easily.  The duds will fail the test, and you will have saved some time.
• Ask for a sample of code including code and SQL.  What they give you is a good indication of the types of things they have worked on and are confident in. 
• Give a coding assignment.  Call it an audition if you wish.  This can be any small coding task, but make it a prerequisite to the interview.  The interview is the most expensive part of the recruiting process.  I like to find a technology the candidate is not familiar with and ask them to produce something with it.  This ensures that the candidate can pick up new things and produce quickly.

I fully recognize that recruiting is not a science.  The worse thing to do, however, is to just talk in the recruiting process.  I’m going to ask my programmer to write complex software, and talking about it is little indication of that aptitude.  I prefer to see some example of the professed ability.  When a candidate easily progresses through all the above steps, it’s pretty certain that the in-person interview will be a “getting to know you” gate that opens easily to an employment offer right away.

[tags: hiring, technical, candidates, recruiting, interview, interviewing, managing, programmer]