Development Ideas For Small Companies & Teams

Having worked predominantly in small companies and teams I've collected a few wisdoms along the way.

General

1. Address your biggest constraint, it's the only one that matters. Repeat
2. Solve only problems you actually have
3. Mandate quality appropriate to the software at hand

Communication

1. Take time to understand stakeholders' expectations and availability
2. Establish a regular cadence for stakeholder reviews and other events
3. Frequently demonstrate new functionality, even if incomplete. Limit the potential for misunderstanding
4. Question things you don't understand, however small
5. Avoid email for in-depth discussions. If you must try using stories, tables and mockups to communicate requirements then talk it through over the phone
6. Adopt industry standard terminology for your domain

Process

1. Reduce process overhead. How often do you use the audit trail you might think you need?
2. Prioritise work with a simple familiar system such as a queue. Consider limiting this to a small number of next features. Get enough detail to roughly size the features then analyse them in detail as Just-In-Time as is tolerable
3. Adjust your process to suit you

Planning

1. Don't start until you understand what "finished" means
2. Plan, but don't expect to have thought of everything
3. Timebox unpredictable tasks and have a fallback plan
4. Work on as-few-a concurrent projects as possible
5. Understand your development capacity and be honest about what you can achieve

What advice would you have for someone in a small company or team?

Why be "agile" when effectiveness is what counts?

It struck me today whilst talking to a colleague how the term "Agile" can easily be misunderstood.

Colleague: "Agile is SCRUM, a load of stakeholders get together in a meeting and decide by committee what development will happen the next week"

"Agile" is not just SCRUM or really any other "Agile" methodology; it seems to me more of a loose collection of principles to organise delivery sensibly and allow large companies to operate more like small ones. Agile, SCRUM, Kanban, XP are just methodologies are just tools, and as any DIY enthusiast knows choosing the appropriate tool for the job is paramount in any life or death shelf hanging scenario.

"Agile", in my opinion, has become over-used and under-understood owing mainly to the aspirational nature of the word. We've seen numerous CVs with a heavy sprinkling of "Agile" dust only to find the candidate has little or no understanding of "Agile" development practices. Worth noting it's also a very easy word for agents to substitute in before others such as project, team, architecture. Agile Architecture?!

Effectiveness over "Agile"-ness

The real goal is not to be "Agile", or adopt some set of sacred practices in the hope that this new religion will suffer none of the weaknesses of the old; but discover a software development methodology that works for your team's situation. A good place to start is by learning the principles of Agile methodologies (see The Agile Manifesto and The Twelve Principles), reading a few different books, sharing experiences with people doing it in anger and not just writers or non-practising conference circuit theorists.

If you can understand these principles, and have a broad knowledge of the tools available then you're in a place when you can start to effect change.

Better TDD By Writing Your Asserts First

Writing unit tests with an Arrange, Act, Assert structure definitely helps but the order often seems at odds with the mental process of TDD. Best practice is to write your asserts first. Here's why:

Arrange First?

Arrange-ing first is virtually impossible. You have no idea what to Arrange until you've written the Act or Assert. This is particularly important when Mocking/Stubbing as the Arrange requires knowledge of the implementation which is exactly what you don't have at this point! * see below

Act First?

Act-ing first seems more reasonable but requires something to first be arranged which can lead you down the dark path of arranging first. If there's any uncertainty about the purpose of the test, which there often is, then this can result in wasted effort.

Assert First

Assert-ing first forces you to clarify the purpose of your test early. Have you ever had that paired conversation of "What are we really trying to do here?", well asserting first is having that conversation. Sure you may not be able to write the entire assert standalone but it will help you to drive the rest of the test and implementation with a clearer mind.

* but I do have knowledge of the implementation

Really? For a trivial implementation great! But if you have an existing external dependency then how do you know that this implementation should call it directly? You don't! Sure it will eventually get called but that may not be the concern of the class under test. Switch back to top down design and let the Assert drive out the interface you require the external dependency to have. Then, and only then, either wrap the dependency to make it expose the interface you require or take the well considered decision to use it directly.

Assert first is really helpful for all but the most trivial tests and can help you achieve that holy grail of loosely coupled, highly cohesive code. Try and see if it works for you!

Breaking The Legacy Bind : A Tale Of Build Automation

I've recently moved teams and following a brief honeymoon on a greenfield web app we're now swimming in the murky waters of the "Legacy Codebase". Imagine a world with no continuous integration, patchy test coverage, untamed dependencies, COM+, a long manual build and deployment process and to top it all off, Visual Source Safe.
If this doesn't make you shudder then best stop reading now :)

Granted, there are probably many worse legacies out there and much of our underlying code is good but it's still a significant departure from the instant builds and frequent releases we had been making.

Science Friction

The initial obstacle faced here is friction in the development process. Friction resulting mainly from the repetitive manual build process. The manual build takes time; lengthening the feedback cycle. It's also tedious and error prone. These two facts alone can prevent even the most diligent of developers from making the refactorings necessary to keep the codebase in good health. Our first job - automate.

Automation, Automation, Automation

Automating the build process to run on check-in removes the tedium of doing it manually and is relatively easy to do with any CI server. Fortunately our code already has a well organised suite of NAnt scripts so we simply configured Hudson, our CI server, to run them and display the test output. A relatively quick win.

If you're not so lucky you could start with automating one part at a time. Just note down your manual process and automate each step in turn.

Migration From VSS To TFS

Using Hudson mandated the source code be migrated from Visual Source Safe to a system more suitable for use with a CI server - in our case Team Foundation Server. The migration itself is fairly straightforward with the Microsoft migration tool and instructions but can be time consuming so plan carefully, especially if your VSS repository is in constant use.

I've previously done this from VSS to SVN and there are probably tools out there to move between most source control systems, but beware, not all features are supported by all systems e.g. VSS pinning, SVN externals. Of course, if you're not concerned about the history, tags etc. you can always just check-in a fresh copy from your old source control to the new one and get going straight away.

Verify The Build

The first build is by far the biggest risk and taking the time to verify it is very worthwhile if you care about the quality of your software. This cost us a couple of days due to build/env issues but it's either that or the entire thing is a no-go so don't be tempted to scrimp here!

Comparison tools such as WinMerge and BeyondCompare can help here to compare the checkouts from each source tree or even build artefacts.

Building For The Future

We're not done here! An automated build is a huge leap forward and allows you to concentrate on skilled activities that deliver more value but it's by no means the end.

Build time is important and reducing it is next on our hitlist. Time spent waiting for a build is often time wasted or forces you into the undesirable world of multitasking. If your build takes longer than it does for you to make a cup of tea then there may well be room for improvement.

Final Thoughts

Dealing with unfamiliar or hard to work with code can be daunting. In my (limited) experience it's all about confidence - get stuck in, and little by little you'll find a path forwards. If you're struggling then I'd highly recommend Michael Feathers' Working Effectively With Legacy Code (ISBN 0131177052) for some inspiration.