Focus on the core: the most important part of the application

Technologies are coming and going faster than every before.  In this environment, how can we provide companies with a good return for their software investment.  Looking back, J2EE was all the rage.  Software executives were banking on J2EE and making significant investments.  The same thing happened with COM+, ASP 3.0, etc.  Managers were projecting significant savings by using these.  Now, where are the savings.  Many applications written with these are being rewritten in newer technologies. 

Why?  Because the applications had no core.  By core, I mean, the center of the application that describes the business domain.  Typically, these are classes and interfaces.  Creating classes using COM+ or J2EE doesn’t an application core make.  The core doesn’t care about surrounding technology. The core is your domain model.  By its design, it’s the most important part of the application, but, done well, it’s portable. 

Look around and see if you can relate to this:  A software team focuses much energy on making the database as good as possible and they create stored procedures to pull back the data as quickly as possible.  They also consider the use cases of the screens that are necessary.  Using technology X for the presentation, they make database table designs and stored procedures that return exactly what the screen needs to show to the user.  Perhaps J2EE or COM+ is used in the passage of information from the database to the UI.  Perhaps Enterprise Java Beans for COM+ components perform some transformation or calculations necessary for the screens. 

Take a step back and remove the screens.  Remove the database.  Is there any application left?  Can you point to any business rules or domain concepts left in the application after the presentation and storage components are removed?  In my experience, I’ve had to answer “no” more than once.  This is absolutely the wrong way to develop software.

Software systems should be resistant to climate change.  The technology climate is always changing.  The core is the most important part of the application, and it should be insulated against changes on the outside.  Over time presentation technologies have changed many, many times.  Data access technologies haven’t sat still either.  We still have the relational database, but the manner of using it is constantly changing. 

Software health check:  Take away the code used to talk to the database.  Take away every screen.  You should still have an application.  You should be left with your application core or domain model and domain services.  Everything should be intact. 

Handle changes in technology gracefully.  If your application has a healthy core, you will be able to upgrade to the next-generation UI.  You’ll be able to change your data access to use LINQ or an ORM without much impact.  If you don’t have a healthy core, any change in technology requires almost a wholesale rewrite.

Any software system is a large investment for a company.  That software is expected to last a LONG time.  By focusing on the core of the application (domain model), the software will be able to weather changes in the technology climate.  By creating a healthy core, your software will be able to drop and adopt technologies as necessary.  Let’s stop rewriting and rewriting and start creating healthy software.

The inspiration for this post came from Jim Shore’ s thoughts.

Baking requirements – Developing with raw ingredients is waste

I have learned an important lesson from my combined experiences at all the places I’ve worked.  That is:  raw requirements cause waste.  A term I’ve used (and have heard others use) is that requirements are either “baked” or “not baked”.  For a development team to plan an iteration, or a scope of delivery, the requirements need to be baked.  If we pull the development team into a planning session, we ensure the requirements are fully baked before the meeting.  Developers will be asking specific questions about the details of the requirements, and answers need to be readily available.

A big cause of waste is when a project manager inaccurately declares the requirements as actionable and the entire team meets.  This is the most expensive meeting you can have.  As soon as the developers ask questions, a discussion ensues among business stakeholders on what the requirements should be.  At this point, the developers sit and listen until the stakeholders finish defining what the system should do.

The above is a strong indicator that the requirements aren’t baked.  There are holes in the analysis, and it comes out as soon as a developer asks a question about the expected behavior.

TIP:  Project Managers:  ensure the requirements are fully baked BEFORE you take up the ENTIRE team’s time.  You may need help from the architect or tester, but ensure the center is not raw when the whole team is pulled in.

UPDATE:  ScottBellware was a bit confused about the context of this post (see comment below), so I thought others might be also.   This post is about behavioral requirements for a single user story.  Very small scope.  Before the team can estimate, this story must be “baked”.  Otherwise, the coding is guesswork.

The first task of a new software project is to build trust – level 300

Please read this post by Brad Appleton (and some links off the post) about building trust in a software team.  The notion is very profound, and we don't talk about much in professional circles.  I, for one, can easily be drawn into only thinking about the technical aspects of software development.  It's easy because it's something at which I excel.  Years ago I went so far as to scoff at a previous employers attempted evaluation of "soft skills", but I know see the importance of it.  Technical skills are necessary, but the greatest techy on earth can be rendered ineffective if no one will trust him.

Driving a “no bugs” team culture – level 200

I've been reviewing Jim Shore and chromatic's upcoming Agile book, and I especially like the "No Bugs" section here: http://jimshore.textdriven.com/Agile-Book/no_bugs.html

Large, dusty bug databases abound.  Some teams have a process where this is unavoidable.  Some teams use a bug database as a roadmap *shudder*. 

Personally, I believer that a "low priority bug" doesn't exist.  If it's a bug, why would you ever think of not fixing it?  If a product manager decides that the current behavior of the system is acceptable for the time being, then why would you call it a bug?  You may find the behavior of the system undesirable, but ultimately, it's the product owner's call what is desirable or not.  Maybe he agrees it's undesirable, but there are other things more undesirable (like the complete absence of several large stories). 

In my experience, poor management leads to a code-and-fix culture – working off a bug list.  It's "easy" if there is just a running list of bugs.  The team stays busy, and you can track work (kind of).  What is hard is to lay out a prioritized road map and manage the growth of the product.  Managing the product is actual work. 

Many things can contribute to a low bug count:  proper roadmap planning, good developers, automated tests, good software design, etc.  I think the average life of a bug is also very important for the team culture.

To drive a culture of "no bugs", bugs cannot be allowed to live long.  If a bug is announced, and nothing happens, the team accepts that the bug is there, and they will fix it "when they get to it".  If someone stops and immediately addresses the bug, then the team knows that bugs are not acceptable.  From a management perspective, I give bugs top priority.  If there is a bug on our wall (red index card), it has top priority – no questions.  The bug is not allowed to live.  This is key for driving a "no bugs" team culture.
 

Iteration discipline: another Agile mind-shift – level 200

In an effective organization, discipline is key.  You can't run a loose ship and expect to be effective.  One of the disciplines that his hard to master is speculation.

Speculation

When working on a story, the developer team might have questions or even ideas for improvement.  A common temptation is to speculate about a solution that seems right to the developer(s).  Sometimes this speculation is correct, and sometimes it isn't.  Either way, developers should not speculate about business value.  Note that I am assuming we have a healthy organization where a product manager (or customer) is actually planning the software and thinking about business value.  In this environment, the customer is responsible (and qualified) for determining priority based on business value.  A customer is charged with knowing the problem domain and making decisions about what software to write to fulfill the business need.  Developers take this business landscape and deliver a technical solution to the business problem.  Developer speculation can hurt productivity when developers start making assumptions about the business problem. 

I talk about discipline because it takes effort sometimes to force the customer to make business decisions.  Developers are the technical experts, and customers are the business experts.  Just as a customer is not qualified to make assumptions about technical feasibility or technical estimates, a developer is not qualified to make assumptions about business value or priority.  When I say "qualified", I mean it is not their role in the organization. 

How to beat developer speculation (or guessing)

  • Keep the customer onsite so that the communication overhead is very low.  That way whenever questions come up, the source of information is right there.
  • Plan the iteration effectively.  An iteration planning meeting should model and task out the work planned for the iteration.  Whether if be one, two, or three weeks, do a good job planning so that all big questions are answered up front (or spikes are declared for specific items).  Lean on the customer during the iteration for smaller, detailed questions.  If you have a hard time planning for your three-week iteration, shorten the iteration to one or two weeks.
  • Focus on delivering software.  Focus on the iteration.  For the individual developer, that means trusting your customer and manager.  Developers are creative and have good ideas.  These ideas should be communicated to the customer, but the customer is responsible for integrating those ideas into the roadmap.  An idea that pops up mid-week should not halt the iteration unless it was something critical that was missed.  Planning (in detail) only a short period of time allows for changing course rapidly since each iteration's plan is defined in real-time.  Remember, the customer (or customer representative) is always planning the future roadmap.
  • Don't tolerate it.  This is more of a management item.  It's a slippery slope.  If a little speculation (or developer-driven business plan) is allowed, then more will follow.  Be clear about the roles of the development organization, and have the developers enforce this discipline within the team.  All technical discussions should focus on iteration deliverables.

What about planning ahead to prevent major technical problems?
Someone on the team should be a strong enough developer to understand these issues.  This is not a role, but more a capability.  If the team is filled will strong developers, then any developer is capable of seeing a roadblock coming.  If the team is more junior with only one senior dev leading the way, then it will fall on that person's shoulders, but this is more of a team-makeup issue.  In practice, with strong people, you have high-quality, loosely coupled, well-tested code that is delivered every iteration.  In this healthy environment, the code is easy to change to react to business decisions down the road.  If you have good people, they won't be coding into a roadblock.

 

What's the secret?
No secret.  Get good people, and they will deliver good software.  There is no cookie-cutter process that magically turns a dysfunctional developer culture into an effective one.  Good people, driven by Agile principles formulate a good process and deliver good software.

How to produce a software product quickly, part 3 – level 300

In my first two installments of this series, I talked about:

These first two guidelines are very important.  The first drives efficiency, and the second drives effectiveness.  Even doing these first two well can leave a team spinning its wheels, however.  If parts 1 and 2 are fully implemented, we are now certain that the team is focusing on the small portion of work that delivers great value.  We are also sure that the team's time isn't being wasted with nonessential or repetitive tasks.  What's next?

Part 3: Use Powerful Tools

A skilled craftsman needs good tools.  First, the craftsman needs the correct tools.  Second, the craftsman needs those tools to be powerful.  A craftsman plowing along with inadequate tools is exerting more effort than necessary.  Why use a hammer and nail when a nail-gun is available?  Why use a screwdriver and wood screws instead of a power drill?

Workstation power

This is the most obvious, but sometimes neglected, tool for a software developer.  Does it make sense to have a highly-paid professional on staff using a mediocre workstation?  The programmer will spend time waiting on a machine.  The answer, of course, is no.  The newest member of my team came on board with a 3.4Ghz Pentium D (dual core) workstation.  1Ghz FSB, 10,000 RPM SATA drive, 2GB RAM.  He had never seen Visual Studio 2005 install in 10 minutes.  Compared to what I'm paying him, his workstation cost pennies.  He spends less time waiting on compiles.  The local build runs very fast as well.  In my mind, it is well worth the cost.

IDE & related tools

Many programmers with whom I talk use Visual Studio.  Just Visual Studio.  Some haven't been exposed to other tools for software development.  First and foremost, Visual Studio is a pretty good solution/project linking and compiling package.  It's pretty poor at helping the coding process, though.  There are a few neat extras you can unlock through SHIFT+ALT+F10 in 2005, but they are sparse.  Install Resharper into the IDE, and it comes alive.  It does use more RAM, but RAM is cheap, and the boost it provides is more than worth it.  Without Resharper, Visual Studio is just a glorified text editor that compiles.  With Resharper, you know about compile errors on the fly, and unused code is grayed out, so you know it's safe for deletion. 

Team tools

It's one thing to give an individual programmer the best tools money can buy.  It's another to focus on the team tools.  There are some tools that all members of the team depend on.  Besides the network connection and the printer, I'm talking about a revision control system and a build server.  It's important to have a quality revision control system.  The team needs to be able to rely on the branching and merging capabilities as well as the commit transactions.  My team uses Subversion.  It has proven itself time and time again. 

The build server is another shared asset.  It must be fast as well since every member of the team will have to wait on it at some point.  The build server can either have the build script run on it manually, or a CI server can run the build when new code is checked in.  Either way, the build needs to run fast, be configurable, and be reliable.  My team uses CruiseControl.Net with NAnt and MSBuild.

Other general, programming and debugging tools

There are many tools that help with a single part of development.  The IDE is the tool that stays open all day long, but other tools are just as critical for specialized tasks.  There is no way I can list them all, but I'll give a run-down of the tools I use:

  • Resharper – productivity add-in for Visual Studio (refactoring, code generation, etc).
  • Lutz Roeder's Reflector – disassemble the .Net Framework.  It's better than documentation.
  • CruiseControl.Net – build server for .Net
  • RealVNC – share the desktop.  Good for pair programming or informal presentations.
  • RssBandit – Keep up with the programming industry through RSS news, blogs, etc.
  • GAIM – Universal IM client.  Use to shoot over snippets of code, svn urls, etc to team members.  Supports all IM services.
  • Google Desktop – Launch programming tools quickly without using the start menu.  Find code files easily.
  • TestDriven.Net – run/debug unit tests right from the code window.  Integrates with NCover for code coverage metrics.
  • Windows Server Admin Pak – Remote desktop to many servers with the same MMC snap-in.
  • TortoiseSVN – Windows client for Subversion.
  • NAnt – build scripting.  In fact, you can script anything with XML using this.  We even use it for zipping up files.
  • NUnit – unit testing framework.
  • StructureMap – IoC container.  Uses attributes for linking interfaces with implementations.  Minimizes Xml configuration.
  • Who's Locking – find out what process has your precious assembly locked.
  • DebugView – hook into the debug stream locally or on a remote server.
  • DiskMon – monitor what's going on on the disk.
  • RegMon – see what keys are being read.
  • FileMon – see what files are being read.
  • Subversion – fast becoming the standard for source control.
  • Ethereal – monitor network traffic.  Find out exactly when and how often your application is communicating over the network.
  • VirtualPC or VMWare – test the software on all supported platforms.
  • Visual XPath – quickly create the correct xpath to get a node from an xml doc.
  • Regulator – Hash out regular expressions quickly with this tool by Roy Osherove.

The list is never ending

Always be on the lookout for tools that will save time or speed you up.  Tools are always improving.  It's important to talk with other professionals from different companies to see what tools are helping them.  Chances are that those tools can help you as well.

How to produce a software product quickly, part 2 – level 300

This is a follow on to part 1 of this series.  I'm talking about how to produce software quickly.  To be clear, I'm not talking about producing brittle software quickly.  Software is too expensive to be built cheaply.  This mantra is a good tagline, but it is so true.  The software I'm asked to produce is important.  It can help make or break the company.  The stakes are too high to take shortcuts.  I've seen software systems launch with a glory of "congratulations" emails flying around.  "The project was a huge success", everyone cries.  Then, 2 short years later, developers are threatening to quick if they are forced to attempt one more change to what is now seen as a complete and utter flop.  Then management calls for a rewrite.  Never mind that there is no introspection about what happened?  How could a roaring success turn into a flop in 2 years?  No, no time for retrospective, we need a rewrite.  And the cycle continues every two years.  That is not what I'm talking about.  The software needs to be sustainable.  It can never become so complicated that newcomers to the team have a hard time figuring it out.  It has to glow of simplicity.  Anything large and complex can't be simple, can it?  I think it can.  In this installment, I'm going to talk about a favorite mantra of mine when working on a software product.

Part 2:  Dodge as much work as possible

You are laughing at me right this moment, but I'm serious.  If I can get away with NOT doing something, I will.  There is an infinite amount of work to do on the product, and my team has to produce business value quickly.  Logically, we have to maximize business value delivered with each unit of work chosen.  Certainly product management needs to prioritize items so that what we work on actually matters, but along with feature stories, technical stories creep in.  What other type of work do we find ourselves doing that doesn't translate directly into business value?

Performance tuning

First of all, if a high measure of speed is important for the product, the customer will communicate that.  Software that flies a fighter jet has to be sufficiently responsive that when the joystick moves, the plane moves with it.  1/2 second delay would be completely unacceptable.  Now think about an enterprise business application.  Think about Microsoft Outlook.  How often is there a 1/2 second delay or more when performing an operation?  Is it a show-stopper?  Is the application unusable when the progress bar pops up to "check email"?  Absolutely not.  It is tempting to stroke our technical prowess and ponder ways to save some CPU cycles.  After all, I'm iterating over that collection twice.  Maybe I could trim it down to just once. . .but those operations are in different classes. . . hmm. . .could I alter my design to save that 2nd iteration?  That sounds absurd, especially when your next operation is calling a web service in another state.  You might save a few milliseconds, but then you promptly wait 1 second for the web service call to complete.  While performance tuning, you have some other high-priority stories assigned.  The next stand-up meeting includes your 4 hours of performance tuning, and the customer can't tell a difference in the speed of the application.  In other words, developer time was spent on something with no business value.  Database access is often another slow area that is optimized.  Database access is an "out of process" operation, and is inherently slower in orders of magnitude than any in-process operation.  A typical application, when profiled, will find 80%+ of processing time* in data access operations, not in-process object model manipulation or screen drawing.

*Statistics made up on the fly with 95% accuracy.

It makes sense to optimize data access then, doesn't it?  I don't know.  Does it?  If you don't do it, what will happen?  Will the customer report that the application is too slow?  Will the customer even care?  Is it a SQL Server 2000 database with 1,000,000 records total and no more than 10 concurrent users?  If so, your database server laughs at the load you place on it every day.  It can serve up your requests with one CPU tied behind its back.

Technical stories

It's easy to accept work given by the customer as "#1 priority".  It's not so easy when the team comes up with technical stores.  Many technical stories have merit, and we, as professionals can see things coming, and we need to be able to responsibly allocate work for ourselves that otherwise would not have been brought by product management.  For instance, we must take reasonable measures to secure the application.  The basic one is the database connection string.  How do we store an secure it.  The customer doesn't know about databases or connection strings.  The customer may love the application, but it a script kiddy can find the connection string, access our database and call our delete stored procedures, then we have a big risk in the software.  Explain that to the customer, and they will understand the time spent on securing the connection string.  Judgement comes in to play, though, because we could symmetrically encrypt the connection string, but then a savvy developer could probably hack our software.  Judgement:  Is the customer paying for protection from ill-meaning savvy developers in the company?  This technical story could quickly explode if it's taken too far.

Back to data access.  Wouldn't it be great if we could somehow detect which table columns were changed so that when we did an update, we only updated that column?  To that, I'd say "that would be terrible. . . if it took more than 10 minutes to implement".  If my product were a super-high-traffic site, maybe.  If my product is a enterprise app with a maximum of 10 users actively on the system at any given time, then no.  1000 users of a system in any given day might not even translate into 10 database operations happening concurrently (during the same second).  In this case, there is absolutely no business value derived with this technical story.  If accepted, we are effectively wasting time.  We need to eliminate waste.

Frameworks

"To build our application right, we need to build a framework first."  Other people have written about this, and I've been there.  In fact, I've been a framework writer.  Boy, did I crank out a lot of code that nobody uses!  If a framework is the deliverable, then ok.  If an application is the deliverable, then we'll be building the application, not a framework.  Besides the fact that it's hard to know what to build before something exists to use it, a framework is a technical story that the customer doesn't benefit from.  I am a big fan of using frameworks to build the application quickly, though. 

Build vs. buy

I default to buy and then entertain convincing arguments to build.  Think about the extremes and then work your way back.  Would you build the .Net Framework?  No, buy it (obtain it).  Would you build your own web framework or would you use ASP.NET, struts, webwork, rails, etc?  Would you build your own ADO.NET provider, or would you use DataReader and DataAdapter?  Would you build your own data access plumbing or would you use an O/R Mapper or code generator to build this mechanical, boring code?  Would you build your own screens of the application completely or would you buy a UI controls library?  All these questions have the same thing in common.  Commonality!  .Net Framework is used in all .Net applications.  Web frameworks abstract away Http plumbing.  ADO.NET providers handle the binary communication with a database.  O/R Mappers deliver the transition from a rich object model to the relational storage view of the data.  UI controls abound to get a nice look and feel by leveraging the UI expertise of the industry.  What is left?  I'll make an assertion.  The only thing that should be left is the code that is unique to your product.  This is the code that makes the application important.  Everybody does UI.  Everybody does data access.  Only you deliver application X.  Your customer needs application X for a specific purpose, and that purpose is modeled by you.  It is the one thing you can't buy.  You can't buy the distinct business value you are delivering with your custom software.  In fact, that value is the only thing custom about the software.  It is what matters, though.  By defaulting to buy, I can dodge quite a bit of work.  I don't have to spend time on fancy UI controls.  I don't have to spend time on boring data access plumbing.  I can focus solely on providing unique business value.

Not created here syndrome

This is the fear of tools and libraries.  Essentially the fear of the unknown.  If it's not from Microsoft and not from us, then we're not using it.  I firmly believe that if Microsoft hadn't delivered VSS, many more shops would have never began using source control.  There are countless tools and libraries available for use that ignoring them can be irresponsible.  It's different in the Java world.  The beginning of a project starts with the selection of tools and libraries.  Often for web apps, they'll choose Struts, Spring, and Hibernate.  This combination gives them the shell of an app, and developers are able to focus on the object model that makes the software valuable.  Hibernate is very common for Java apps.  Microsoft doesn't have an O/R Mapper.  Once they do, no one will ever write data access code again (mark my words) in enterprise apps. 

In the .Net world, it can be a struggle because some folks think that Microsoft is the only entity capable of producing a quality library.  Not created here syndrome leads to 3 times as much work as necessary.

YAGNI:  You ain't gonna need it

If the customer specifically asks for a function build it.  If not, don't.  Let's say your customer needs a windows app for managing contacts (I know, trivial example).  The customer needs to be able to add, edit, and delete contacts.  Say you start working on the add feature, and you speculate that you should probably make a screen so that several can be added quickly.  It seems like a logical extension to the feature, and it seems that it could provide value.  The danger is that while you work on the multi-add screen, the edit screen isn't getting done.  A savvy customer will quickly question and correct this type of behavior.  It might have been a logical variation of the feature, but it's not the most important thing.  Like I've said before, there is an infinite amount of work to do.  The art of product delivery is focusing on the small subset of work that will be valued the most.  Essentially, if I demo an incremental build to a customer and I have to point out something, then we point in a feature that could have been deferred in exchange for something more important.  The customer will come to the demo asking if three things are done:  add, edit, and delete.  Until those 3 things are done, the product team has no right to insert other work in front of the key stories.  With the YAGNI mantra, I assume that if the feature isn't specifically requested, it isn't going to be needed.  Maybe it'll be needed later, but that's just speculation.  When the priority is to deliver value quickly, I have to be able to defer nonessential work.

Conclusion

It's somewhat of an art to be able to filter that infinite pile of potential work done to a small subset of work that will satisfy the customer.  Ratholes and scope creep are very dangerous to the timely delivery of software, and I keep in my mind always:  "Can we put this off 'till later"?

How to produce a software product quickly, part 1 – level 300

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]

Review James Shore’s new book “The Art of Agile Development” online – level 200

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.