Jeremy D. Miller -- The Shade Tree Developer

Starting a new Project

• Would you do it differently today?

  A year and a half ago I wrote a post called My Gameplan for Starting a New Project from Scratch that just detailed my thoughts on starting up a new project.  I was asked via email last week if I had any changes to that post.  Yes, absolutely: Follow it Through! Don't jump into the work too early without a good story backlog definition, an understanding of the goals of the system, and some inkling of the expectations of the client (which are undoubtedly going to turn out to be ridiculously unrealistic). All processes, even XP and Scrum, have some sort of fuzzy project conception phase.  The activities that you perform in that phase are crucial to the success of the project by preparing the field, but easy to neglect because there isn't much pressure upfront and the feedback loop that says "you're wrong!" hasn't started yet.  On the other hand, I think you need to work with a sense of purpose early in the project to get through that initial phase and get started.  In My Gameplan post I talked about the importance of getting momentum early on in the project.  That's largely based on my experiences in a large organization that let the early phases drag on way too long.  After doing three projects and starting a fourth since that post, I'd still err a little bit on the side of starting the coding in earnest too early rather than too late.  I did have some issues with coding outrunning the build, test, and deployment infrastructure.  Take care of that stuff as early as possible.  Especially early on the project, if you see chances to add some automation to reduce friction, do it right then.  Investments early on pay off more in the lifecycle of a project.      Posted May 01 2008, 11:04 AM by Jeremy D. Miller with 4 comment(s) Filed under: Starting a new Project

• New Client, New Project - What do you want to know?

  I'm starting at a new client in a couple weeks.  Last time I did this I created My Gameplan for Starting a New Project.  I think it mostly held up with a few exceptions, mostly around the quality of the upfront analysis leading into the initial story list.  I think next time I'd like to get just a bit more time and much more access to the business experts for building up the initial story list and release estimates.  Last time I was worried about the effects of Analysis Paralysis and gaining momentum early.  I want to revisit that just a little bit and think about the questions I want to ask my new client team right off the bat: What constitutes success for this project?  What's the primary goal? What's the iron triangle constraints?  Time, resources, or scope? Who are the stakeholders?  End users?  Who's paying for this thing? Who are the business and technical experts that we'll need at some point? How much contact and interaction are we going to be able to have with the end users and business experts?  Are we going to have a customer representative or advocate embedded onto the team? What are the legacy systems we'll need to interact with?  I want to know the challenges around the legacy system or existing infrastructure -- and you know there's always something nasty about a system of any age.  What external teams are we going to need to interact with? Is the team self contained (testers, analysts, developers, and a PM all together under a single organizational structure and team), or is the testing team in a completely separate organization?  Obviously, I think the first choice is far superior in terms of results and efficiency, but you gotta play the cards you're dealt. Obviously, I'm going to try to use Agile practices (mostly XP with some Scrum flavoring).  Is that acceptable to you?  Do you have any experience with a disciplined iterative approach (waterfall is still by far and away the most common SDLC)?  What kind of project management practices do you use today?  How about development practices?  I would try to use Continuous Integration and Test Driven Development no matter what, but other practices can be harder to sell or do in non-Agile organizations.  As an immediate example, I want to do Acceptance Test Driven Development anytime the analysts and testers can and will play along (I think we can in my next project, but couldn't on my current project). A very important question:  can the team exert a great deal of control over their practices and process?  Or are they bound by a corporate standard? Assuming that you can control your own process, what are your pain points today in your existing process?  Theoretically as a consultant, you're supposed to do something to add value ;-) Where's the build server, and can I and the team have full control over it? What is your policy towards using Open Source software?  Obviously I'd never advocate any tool under a viral license, but how about less restrictive licenses?  Do I get my head chopped off for suggesting OSS tools when they're superior to the built in or nonexistent Microsoft offerings? What is it that you're not telling me?  It's worth a shot ;-) Can I get my laptop in the network?  More importantly, what am I not supposed to do on your network.  Never hurts to ask. You are using Subversion right?   What'd I miss? Posted Mar 23 2007, 12:57 PM by Jeremy D. Miller with 12 comment(s) Filed under: Starting a new Project

• Noah, I want you to build an Ark

  Think about this for a minute, say your Noah, walking down the street, minding your own business, and a big voice booms out "Noah, I want you to build an Ark.  When can you ship?"  Here's the proper response -- "Right, what's an Ark?"  When the big voice says "it shall be 200 cubits by 40 cubits by 60 cubits" you respond with "Right, what's a cubit?"  And so on and so forth.  The point being that you cannot give an accurate estimate without a detailed understanding of the tasks involved to carry out the development work.  I don't think you can efficiently develop a "complete" list of developer tasks upfront, but you've got to get deeper than "build an ark" in release planning.  "Build the rudder" and "create the keel" and "attach the ramp" are much more actionable user stories. My project has run into some difficulty in project and story management (in no small part because *I'm* sharing a bit of the pm hat).  Specifically, we as an entire organization, missed a lot of complexity and fine grained detail in going from a traditional functional and technical specification document to detailed user stories and tasks.  The warning sign that I (and everyone else) missed was vague, amorphous story titles like "Create a New Invoice" and estimating that story in release level planning.  That simple "Create New Invoice" CRUD screen has turned into a myriad of user defaults, cascading dropdown lists, about a dozen new fields, and a fair amount of branching logic because there is at least four different logical types of "Invoices." I made a conscious choice early on in the project that we would move into coding as quickly as possible because I felt that it was more important to build up momentum early than run into analysis paralysis by trying to get the story list perfect upfront.  I knew that our user stories were vague and that there would be plenty of new stories spill out as we got an iteration or two into the project.  What to Do? Assume that your first estimate sucks and revisit it as you go.  Revise estimates early on as you learn more about the problem domain in the first iterations.  You always discover new stories as a result of early development.  Update the story backlog and communicate those changes to your management and customer as early as possible. Every development task or need should be represented by a story card that is visible to the team and management.  My current client depends on developers "knowing" how to interpret requirements and apply them to their user interface.  That domain knowledge by their developers is a great thing, but those implicitly understood tasks have to be expressed explicitly in story backlogs so that the project can be accurately sized and controlled.  My team is all new to their organization and the dependency on implicit tasks has got us into trouble with our initial release planning.  In retrospect, we should have pushed harder upfront to understand the details Get a "Domain Expert" on, or very readily available, to the development team.  Specifically, a domain expert who has a vested interest in your project succeeding.  I think this rule applies to any type of process or team.  The only difference compared to waterfall techniques is that iterative or Agile projects admit that fact.  The most successful project that I've ever been a part of had the business sponsor and team engaged on a daily basis (it wasn't an Agile project, it was the 20-something Jeremy works lots of hours process). In release planning, get the Business Analyst(s) to walk through candidate stories, out load, in detail (basically, do a lightweight JAD).  Throwing a specification document over the wall to the downstream group and running away has to be the dumbest aspect of waterfall programming.  Face to face communication conveys much, much more information than spec documents.  I remember now how utterly moronic waterfall thinking can be.  Your project stands a much better chance of success if the developers, requirements folks, and testers interact on a daily basis and pull together for a common goal. Write acceptance tests early in iterations.  We've found a lot of requirement needs by writing detailed acceptance tests with Fitnesse because it flushes out a lot of technical detail that isn't apparent at the "spec" level.  The same problem exists for software designs, especially upfront design specifications.  I've seen too many teams create design specifications with no more detail than a single UML component diagram with a box for "the Invoice component" and an arrow pointing to the "shipping system."  I'm extremely dubious about the value of doing a *lot* of UML modeling upfront before coding, but it's even more ludicrous to say "we've got a design" in a waterfall shop just to check off a process step when you really don't know much of anything. Geek points for whoever tells me what the title of this post is from.  Hint, he used to be really, really funny before the goofy rainbow colored sweater era. Posted Dec 06 2006, 07:48 AM by Jeremy D. Miller with 9 comment(s) Filed under: Starting a new Project

• Getting Started: How often should you check in?

  Yesterday my team was talking about how often the CruiseControl.Net build ran each day.  The question arose, how often should we check in?  For example, our team of four developers creates about 20 successful builds in a full day of coding and I think that sounds all right.  I can't imagine there being a definitive answer, but you should strive to check in every time you hit a stopping point , and come to a stopping point as often as you can.  Much of the point of doing Continuous Integration is to get more feedback from the system and work in smaller steps.  Stopping to do a full check in dance (update from the trunk, run the NAnt script with tests) is a way to verify that your code can be integrated into the trunk with everyone else's new code.  Doing frequent check in's can keep those nasty merge problems away.  Some tasks are going to tear up the code for longer periods of time.  If you've got stale code because of one of these Herculean tasks, update your code from the trunk as often as possible to reduce the risk and burden of merging later.  Frequently run the entire suite of unit tests as you work if you're making changes that might ripple out into other areas of the code. The key concept for me in all software development activities is rapid feedback, reducing the cycle between doing something and verifying that something.  Frequent check in's ala Continuous Integration are definitely in line with that philosophy.  I'm going to assume that we all agree that checking in code that doesn't compile or pass its unit tests is a bad thing.  Broken Windows and all that stuff.  The unit tests don't provide much value if you ignore them or don't run them.   Posted Nov 07 2006, 07:28 AM by Jeremy D. Miller with 1 comment(s) Filed under: Starting a new Project

• Week 2: Scheduling and Coordinating the Work

  Continuing the "Getting Started" series.  My team just finished our second week.  Luckily enough we were able to get through release planning quickly and start Iteration #1 on Tuesday.  CruiseControl.Net is up and running.  I kept a list of the topics that came up this past week that I might want to talk about in the blog, and a single theme pops out:  how to schedule and divide the work. First, some little things: Check in code often.  Constant check-in's should keep the overhead of merging to a minimum.  Continuous Integration is an attitude, not just a tool. Work in small steps.  That means write a unit test's worth of code at a time.  The TDD red bar should be a short phase and there really shouldn't be many times when the code can't compile for more than a few minutes.  Working in big chunks without verification is what brings out the inefficient, marathon debugger sessions. If you're helping a team learn TDD from scratch, don't let them start early with dynamic mocks.  Let them get a handle on TDD with work that leads to state based testing first. When you're doing TDD, try to break the work into small tasks.  From that task breakdown, think about how each task or step could be tested.  Your low-level design pretty well follows from testing one task at a time and building up to the whole.  Code from the bottom up! Build business functionality first, and let the infrastructure come second to enable the business functionality.  I tried to avoid this, but it happened anyway.  We got a bit caught up in UI infrastructure and didn't get much functionality built.  The danger of focusing on infrastructure solely upfront is the risk of getting tied down in purely speculative coding that doesn't deliver any value in the end. Check in comments!!!   Iteration #1 Work I think the real goal of iteration #1 is to create knowledge more so than code.  You will never produce as much functionality in iteration #1 as you should in later iterations.  The first iteration almost has to be concerned with creating a common vision of how you're going to build the software, especially if the team hasn't worked together before.  You could lay your ears back and code away at full speed, but you'll pay for it later with either technical debt or longish design sessions with the rest of the team explaining (and arguing about after the fact) the technical approach.  I sincerely believe that people understand design strategies far better when they have been present for the formulation of that design strategy. I say this mostly to try to alleviate the stress from first iterations when the code isn't flying off your fingers into the IDE.  When you're loading up the first iteration you really shouldn't count on doing as much "work" as you will later on.  I think this is in line with Eric Evan's idea of Knowledge Crunching. Splitting the Work I've seen two real issues this past week: The beginning of the project is much rougher for merge conflicts than it will be later on in a bigger code base.  Strive to find stories that can keep the multiple pairs out of each other's way.  Even so, it still takes a lot of communication around work on shared or foundational classes.  A simple "hey, we're about to rename this class.  Is that okay with you?" goes a long, long way to alleviating the worst of the merging issues. Rotating people through different areas of the work.  Like I said in the previous section, I'm more concerned about creating the shared understanding upfront than cranking out code right now (on the theory that this shared understanding will pay off immediately in the following iterations).  We're just trying to be cognizant about rotating people through different kinds of story work.  It's a bit incumbent upon each developer to speak up when they think they're getting siloed. Serialize the Work For best results, you should focus your efforts on completely finishing active stories before starting any coding work on new stories.  You should only start coding work on a new user story if you're completely blocked or out of work on the previous stories.  First you really do have to internalize the idea that the development team as a whole can only take credit for production ready code.  Once you do that, which outcome at the end of an iteration below is better? 5 out of 10 user stories scheduled for the iteration are production ready.  3 of the others have not been started.  All 10 stories for the iteration are in some sort of intermediate state.  Even though both outcomes may reflect the same amount of effort by the developers, only outcome #1 provides any real business value. You also need to get something in the hands of the testers or reviewers by at least mid-iteration if you're going to make your iteration.  Besides, the human mind just doesn't handle context switching all that well. Ordering Stories XP dogma states that you order the user stories in terms of business value.  In practice I've never found that to be enough.  There's always constraints of some sort that have to be accounted for in your schedule: What stories are understood well enough to work on?  You're going to need to look ahead a bit to make sure you always have enough stories ready to go at the start of each iteration. Does one story depend on some infrastructure that's built in a different story? What stories can be worked in parallel?  If having two or more stories involve the same area of code, you may want to serialize these stories to prevent some nasty merges. Eliminating risk.  This might be technical risk of some sort, but it could also be business risk.  Our project is user interface-intensive.  One of our best ways to reduce risk is to get the user interface in front of the client as soon as possible to make sure the UI is acceptable and meets the business needs. External constraints.  You're almost always dependent upon external groups or even external companies.  You simply cannot do work that depends on a different team without coordinating with them first.  We're going to try to get some representation from the server side team in our iteration planning meetings to deal with this coordination. Breaking up Stories Don't hesitate to break stories into small units.  For example, there isn't any rule that says you have a one to one relationship between a screen (especially a complicated screen) and a user story.  As long as a user story provides some amount of business value and can be tested by itself, it's fine.  Smaller stories are easier to estimate and drive to completion.  Dividing the work into smaller chunks helps to get working code in front of the users and testers earlier in the iteration to make their jobs easier. What I don't feel good about are stories like "Capture the information in the screen" paired with "Persist the information to the database."  Capturing the information in the screen is just a task.  It doesn't really provide any value until it really works from end to end.  Dividing the work into "Capture header information" and "Capture details" and maybe even "Validate the user inputs" into separate stories is much more acceptable to me. Can You Have Technical Stories? I say preferably not, but it's not the end of the world.  As long as the stories are very focused into a specific technical task to enable the following business stories, I'm fine with technical user stories.  I've often found it easier to pull out a shared technical dependency of multiple stories into a technical story for easier tracking.  What's definitely bad are stories like:  "Create the Data Access Layer" or "Create the Model View Controller Framework."  Those stories are black holes. Posted Oct 15 2006, 11:05 AM by Jeremy D. Miller with 2 comment(s) Filed under: Continuous Integration, Test Driven Development, Starting a new Project, Pair Programming

• More Tips for Getting Started with Agile

  Welcome to my stream of conscience series about topics that are popping up on a new team that's largely comprised of folks new to Agile practices. The "Build" Should Remove Project Friction Part of a full fledged Continuous Integration effort is an automated build script that can lay down all of the environmental dependencies of a system.  In other words, running the build file on a local workstation should make your workstation able to run that code.  When you're updating your version of the code, especially for the first time or with stale code, you might make a habit of running the build file before you begin coding to guarantee that your box is ready to execute the code. On the other side, be a responsible member of the team and add any new environmental setup from your work into the automated build script.  By putting that setup into the build file you've accomplished two things: You've effectively documented the environmental setup dependency You're propagating the environmental change to the other developers, the build server, and the test environments Here's a story about an irresponsible developer that routinely made environmental changes to the code without adequately warning the other developers on the team.  I'll call him "Jeremy."  One day Jeremy came in early and created a new web service project for some of the new backend functionality.  Jeremy let Visual Studio.Net make the IIS virtual directory for him.  He then proceeded to write integration tests against the new web service and tied the user interface to the backend.  He then checked in and went to lunch.  The other hapless developers updated their code and quickly discovered that the application no longer functioned on their workstations.  Because they didn't know about the new virtual directory dependency that Jeremy had introduced, they spent a fair amount of time trying to troubleshoot the application failure.  At the some time the testers pulled down the new build and discovered that the application no longer worked.  They were unable to work at all.  If Jeremy had simply added a task to the build script to setup the proper virtual directory (and used CruiseControl.Net), he could have saved the other developers' and the testers' time. When Estimating, Remember the Whole Story estimation is an important activity that feeds the project management types with increasingly accurate information they need to plan the project timeline.  It's not fun, and it's definitely an "eat your broccoli" type of activity, but it's your best tool to maintain a sustainable pace. In a typical Agile process you spend a fair amount of time estimating stories.  Contrary to some popular belief, Agile isn't (not supposed to be) pure cowboy coding and unplanned chaos.  The core of Agile project management is adaptive planning.  The plan is constantly updated to reflect the latest estimates from the developers.  The crucial assumption is that developer estimates basically suck on day one and get progressively more accurate as the project proceeds.  A crucial part to better estimates is to take a broader view of the development work rather than focusing on the code only.  Making a story cross the line into the "done, done, done" category involves more than just the code.  Many, if not most, developers are consistently overly optimistic in their estimates.  I'm betting part of the culprit (beyond developer hubris) is failing to pay attention to the ancillary tasks that take place as part of development.  When you're estimating a story, you need to also account for the time it's going to take to make extensions to the build automation, test automation support, and other sorts of overhead.  For example, a user story might only require a couple hours of coding, but spawn so many possible permutations of input that writing automated tests takes several times longer than just the code.  You might even make a point of calling out these extra "hidden" tasks out explicitly when you're estimating stories. Sustainable Pacing requires some Trail Blazing One of the attractive tenets of Agile Development is Sustainable Pace.  I think everybody agrees that eliminating overtime is a good thing, but achieving that goal is a different animal altogether.  There's also a flip side to Sustainable Pace, the development team cannot afford to be idle or working ineffectively at any point because they're waiting on some other input like requirements or infrastructure.  To maintain a level of efficiency you need somebody to be out a little bit ahead of the developers making sure that the next batch of stories and environment needs are taken care of.  That developer abstraction layer is essential.  I don't have any particular recipes for solving this problem.  My previous team never entirely solved the problem.  Ideally I'd like to have dedicated business analysts or even testers that stay just ahead of the developers to insure that the developers are always fed with detailed requirements for the next iteration's stories.  Since we don't have dedicated BA's, I'm suggesting that my new team follow a practice of identifying analysis holes for iteration n+1 during planning for iteration n and work analysis stories an iteration ahead to maintain a steady path.  I'd like to prevent cases where the development team is completely idle waiting for requirements decisions to be made.  When I was very new to Agile developement I sat in and listened to two different teams have an impassioned argument about whether or not the analysis stories were a good thing.  I can't say that I understood the arguments on either side then, so we'll try it anyway and fix it later. Long iteration kickoffs can hamstring a team.  If iteration planning becomes overly long, some pre-tasking meetings near the end of iteration n-1 might make planning for iteration n go smoother.  Getting to day 1 of an iteration and realizing the analysis work isn't baked or understood isn't a good feeling. In the end, my goal is to develop a team and ecosystem that can continuously pull down stories for an iteration, finish off those stories within an iteration, and repeat without pause for the duration of active coding.  Meeting that goal means having half an eye cocked looking ahead and removing obstacles to the developers (and testers). Posted Oct 09 2006, 12:44 PM by Jeremy D. Miller with 13 comment(s) Filed under: Continuous Integration, Starting a new Project

• Week 1 Questions: How do you organize your NUnit test code?

  I can see more of these little posts about setting up a project coming up, so I made a new category called "Starting a new Project."   My team discussed how we were going to organize the NUnit TestFixture code.  We talked through the normal options and pretty well decided to go down a very generic path. The first decision was how to group unit tests into TestFixture classes.  I brought up two alternatives: TestFixture class per concrete class (by far and away the most common approach) TestFixture class per user story I voted for grouping the tests by the class that they test.  Another developer liked grouping by user story.  We ended up adopting .  I've done the grouping by story or feature before in StructureMap and felt it worked just fine, but it might just be a sign that I had a Shotgun Surgery code smell going on.  For example, when I retrofitted "Setter Injection" into StructureMap I created a separate TestFixture class that tested the relevant changes across about a half-dozen classes.  I kind of liked being able to write all the new unit tests in a single file rather than doing so much switching back and forth to write a single unit test in several different files.  As I recall, it was almost purely additive coding rather than changing existing code.  The drawback with this approach is that the unit tests for a single class *are* scattered across story test fixtures.  When I'm changing an existing class with new behavior I want to be able to run all of the unit tests for just that class (simple right click and "Run Tests" with TestDriven.Net) as I code for more targeted testing feedback.  I don't have a hard opinion about this issue, but I feel like the per concrete class approach is the choice by commonality if nothing else. The second decision is where do the TestFixture classes themselves go.  I know of a couple alternatives: Put the TestFixture classes inside the production assemblies.  In this case the team will denote a naming convention to put the TestFixture classes in child namespaces, often within each production namespace.  When the team is making a production build the unit test code will generally be filtered out so that the unit test code does not ship.  The obvious advantage is more resiliency to member visibility issues for teams that are aggressive about making types and methods "internal."  Some people also like being able to always find the unit test code directly under the production code.  Personally, I don't like this approach.  Filtering out the test code is extra overhead to maintain in the build automation scripts.  I think it makes the production code a bit harder to look at in Solution Explorer because there's so much more noise going on.  I haven't really seen that many problems with member visibility by putting the test code into separate assemblies, even without the InternalsVisibleAttribute trickery.  You simply make anything that needs to be tested public and away you go.  As far as being able to find the relevant TestFixture class for each class, as long as you follow a consistent naming convention you can quickly find the TestFixture with something like ReSharper's CTRL-N shortcut. Put the TestFixture code into a separate assembly for each production assembly.  I don't really know why people like this pattern, unless it goes back to being able to find the TestFixture easier through only the physical file structure.  I don't like this approach for a couple reasons.  The first, and most immediate, is that for big changes I often want to run all of the unit tests at one time.  Separating things out into multiple test assemblies just adds to the mouse clicks and build automation overhead.  Yeah, you can always run all of the tests for a solution, but as I'll cover in the third bullet, that's not necessarily what you want to do on a regular basis.  The second reason isn't quite as obvious, but it's a very real concern.  At my previous job we found that the compile time for a big solution seems to be more dependent upon the number of projects than the total amount of code.  At one point we inherited a code tree that had 55-60 projects and took upwards of 4 minutes to compile.  We brought that compile time to under 30 seconds just by combining fine grained assemblies into bigger assemblies based on deployment.  Part of that effort was combining about 15 test assemblies into only 2-3 assemblies.  A slow compile time is deadly for productivity because it slows down the feedback cycle of virtually all coding activities. Lastly, and this is my preferred approach, create two different assemblies for testing.  One assembly holds the unit tests (fast tests) and the other has the integrated tests (slow tests).  Generally, you parallel the namespace structure of the production assemblies.  The benefits to this strategy are being able to run all of the unit tests at one time, faster compile times, and less overhead in maintaining the build scripts.  An additional issue is that the two types of tests may have different configuration requirements.  The integrated tests will definitely need configuration for external resources like database connections and web service urls.  The unit tests shouldn't need any of that stuff, but may require a completely stubbed out version of the configuration files (I'm thinking about using an IoC tool here). Anybody got a different approach?  I'm all ears. Posted Oct 07 2006, 08:32 PM by Jeremy D. Miller with 18 comment(s) Filed under: Continuous Integration, Test Driven Development, Starting a new Project

• Getting off the Ground: Week 1 Questions

  Continuing the saga of "getting a project going," a couple little issues have come up I thought would be "sponge-worthy" "blog-worthy."   Do you write Unit Tests for Private Methods? Emphatically, no!  The private methods should be getting tested through the public methods.  One of the more common misperceptions about TDD, or really unit testing in general, is that you write a unit test per method.  That's not entirely accurate.  You write a unit test per external usage of the class, not in a 1-1 ratio of test to method.  If you're truly writing your tests first, you nearly guarantee full coverage.  Besides, writing a unit test to a private method is a form of tight coupling to the implementation of the class being tested.  That kind of tight coupling between test and class is the most common cause of brittle tests.  Brittle tests partially negate the value of unit tests by making change expensive because of breaking the existing tests.   Can you write Technical Stories? According to some literal readings of XP dogma, each story must be connected to a business need.  I think that was mostly intended to rein in the tendency of developers to obsess over technical infrastructure work instead of business value.  In practice though, I think it's fine to have some purely technical stories, as long as they specifically enable a business story in the current or next iteration and no more.  I think that splitting out a pure play technical story makes estimation and tracking simpler.   I'm happy to leave some sorts of work like build script enhancements be handled by "velocity" as ongoing overhead, but I've seen at least one control freak project manager insist that he have visibility into these activities as a story card that can be tracked.  I'd be a little bit weary of that.  Technical stories and spike stories need to be controlled.  There has to be a definitive goal of the technical story to know when it's been accomplished to avoid unnecessary Architecture Astronautics.  If it's purely a "spike" just to learn about something or create a better estimate, maybe you just cap the story upfront with a maximum number of hours the team is going to spend on the story.   Perfect Estimates versus Let's Get Going This issue is legitimately worrying me at the moment.  I don't feel like we have enough information to go into release planning and create usable .  The team and the customers are getting itchy to get on with development.  Projects that stew too long in "Envisioning" or "Planning" or "Inception" or whatever run the risk of miring down in analysis/paralysis.  I think coders without coding are effectively fish out of water.  They can still move around a little bit, but they lose their vitality fast. I'm definitely feeling like there's significant tension between Control/Predictability and project throughput (cue the inevitable reference to the Heisenberg Uncertainty Principle).  Spending more time on analysis may get us better control with more accurate estimates, but I think it's sucking down our energy level.  On the other hand, I think we might be far better off just to jump right into the first set of stories.  We have a very logical first (large) story to work on that is fairly understood.  Maybe we don't start with perfectly known scope, time, and estimates, but I'm very certain that it'll get the team working with much more energy.  As long as the client's management understands that the estimates will be changing after that first iteration, I really don't see much downside.  I'm much, much more worried about establishing a level of energized work and momentum than perfect predictability.   Estimate Together This is absolutely crucial.  Even though it might sound more efficient to divide up the stories by individual for estimation, it's not.  Part of any kind of useful estimating is breaking the work down into finer grained tasks.  That task breakdown is a very powerful form of team design.  An XP team often creates and socializes their technical approach during tasking.  Doing tasking and estimating inside silos hampers the flow of information through the development team. Posted Oct 05 2006, 01:35 PM by Jeremy D. Miller with 2 comment(s) Filed under: Test Driven Development, Starting a new Project

• Check in all your binary dependencies into Source Control

  In the vein of "getting started," the question came up today about how to access shared binary tools like NUnit or NAnt.  I'd say that the best practice is to have all the binary dependencies checked into your source control repository and use those copies of the tools (operating systems & database servers obviously don't apply).  Don't depend on a GAC-ed copy of NUnit or NAnt. WHY?  One of the tenets of a Continuous Integration strategy is a single, authoritative source repository for the application, including binary dependencies.  There are two end goals: Know exactly which versions of what (NUnit, NAnt, NHibernate, NEtc.) your code depends on Be able to walk up to a clean machine, checkout the code tree, run the automated build, and voila -- you're ready to go.  Depending on a GAC-ed copy of NUnit, for example, defeats this goal.  Posted Oct 04 2006, 03:35 PM by Jeremy D. Miller with 9 comment(s) Filed under: Continuous Integration, Starting a new Project

• My Gameplan for Starting a New Project from Scratch

  I'm starting my new job today and kicking off a new project this week.  The organization is relatively new and this is the beginning of their first .Net product.  Other than some interesting integration needs with an existing backend, the project is greenfield.  Everything has to be built from scratch.  Jeffrey Palermo was trying to talk me into keeping a Jim Shore-style diary about this project and my experiences.  I think I'll try to do that too, but in the meantime, here's my initial thoughts on how to get the project rolling.  As usual, I'm viewing the project through the Agile paradigm. Big Mo' My consistent experience spanning companies, teams, and processes is that projects that start with energy and write useful code early are far more successful and smooth running than projects that take a long time to get going.  Establishing momentum and a sense of energized work are essential for a successful project.  Going back to my first "real" programming job I saw both extremes within a year.  On my first project we started with excitement and energy by building a demonstrable prototype and got the business behind us immediately.  There was a sense from day one that we were going to do something good.  To this day I still consider that project the most successful I've ever been on (and no, it wasn't an Agile project).  On the second project we started by doing 6 weeks of "current state analysis" and worked another 6 weeks to (in)validate the consultant's recommendations.  That project got mired in analysis/paralysis for months and never delivered a single line of working code.  Complete and utter failure. I honestly think it's more important to start early and seize some momentum for the project rather than spend more time getting the vision perfected.  Even if it's just architectural spikes, I want code being written very early to get a sense that the project is real and moving.  I'm pulling this figure out of thin air,  but my hope is to start writing production code within an iteration structure in about two weeks.  In physics, the effect of friction is greater on a resting body than a moving body.  Software development is the same way.  Get going. Step #2:  What are we building? Step #1 is "steal underpants."  Step #2 is to get a handle on what we're building.  We know that there are some specific architectural risks that need to be spiked, but without a direct connection to the immediate business need, that technical work may be purely speculative and potentially wasted.  The technical work must be grounded in the actual business priority.  I think the most important thing upfront is to start creating a common vocabulary (ubiquitous language) around the business problem for the team.  Agile processes are usually built around expansive communication between team members.  The fastest way to foster that communication is to develop a ubiquitous language.  For example, what are the business entities, transactions, and user types called?  From a purely project management perspective, I think the critical path is going to be creating a story backlog of requirements.  The requirements need to be enumerated and fleshed out just enough so that we can go into the Release Planning meeting.  Iteration 1, and development in earnest, cannot start until we have a release level collection of prioritized requirements (user stories) with rough estimates.  I'm not too worried about having the first set of stories detailed out upfront because the first iteration is always slow as you deal mostly with architectural and design issues.  Learn the Context These days there's basically no such thing as an application that lives in isolation.  Most applications live inside the context of an existing IT infrastructure.  One of the first things to do is to start learning about the context of the system.  What other applications will it need to interface with?  Who manages these systems?  How do you get your needs onto their project or iteration plans (big concern of mine at the moment)?  Is there existing data that needs to transferred?  If you're doing a rewrite, where is the old code?  What are the technical constraints of the client?  What's the overall strategy of the company, and how does this new system fit into that strategy?  I'm in the middle of trying to understand just those questions. Iteration #0:  Prepare the Field On a project 2 1/2 years ago we lost half of the first iteration to problems with CVS issues (CVS is right behind VSS in my source control enemies list), partly due to my ignorance.  That was one of many issues that set a bad tone for the project right off the bat that we didn't ever entirely shake.  I'm never doing that again.  From that moment on my projects have always started by solidifying the software ecosystem first. When day 1 of iteration 1 rolls around I want to be able to focus on coding and design, not fiddle around with setting up build scripts, source control, and test environments.  To make the most of your time, work an Iteration #0 that takes place to do the "NAnt-y" work to prepare the field for development.  Iteration #0 can take place in parallel with building the story backlog.  By the start of Iteration #1 I'm suggesting that we have: A source control repository already in place that everyone knows how to access.  We're going to be using Subversion (free, solid, easy to use) Shell of the project solution, including a project for unit tests and another for integration tests.  We'll probably take advantage of TreeSurgeon to bootstrap the effort. Binaries of the development tools (NAnt, NUnit, RhinoMocks, etc.) the team is going to use checked into the source control repository.  I like to put these in a folder called "bin", other people call it "tools."  Under no circumstances do you ever count on these tools being installed into a workstation's GAC! An initial build script (probably NAnt delegating to MSBuild for the compile) that: Cleans out older build products Versions the code according to the current build number Compiles Runs unit tests and integration tests (NUnit most likely) A little bit later we'll add test coverage with NCover and code metrics with NDepends Get CruiseControl.Net setup to run the builds from day 1.  Continuous Integration needs to be engrained from day one, and besides, it's easier to do it upfront and let it evolve with the system than it is to retrofit later. Everybody needs to have the CruiseControl.Net system tray client to monitor the builds Get the ancillary tools (ReSharper, TestDriven.Net, TortoiseSVN) installed on the development machines. Research tools for acceptance test automation.  Normally I'd say FitNesse/FIT right off the bat, but I'm going to look at some WinForms specific tools like SharpRobo and NUnitForms. A Social Contract for the Developers Right off the bat the team needs to start creating a "Social Contract" for the way they're going to work.  This contract includes thinks like: Naming standard for projects and assemblies Agreeing on some sort of "Check In Dance".  Build hygiene needs to be socialized through the team.  This is a good point to make sure all of the team knows how to run the local builds and access information in the Continuous Integration builds. Coding standards (keep it light) Where to put unit or integration tests and how to name test fixture classes What tools to use Initial design strategies.  I wouldn't get carried away with this, but right off the bat I want to talk about using the Model View Presenter (Passive View & Supervising Controller) patterns. Are we doing pair programming, and what percentage?  Are we mandating Test Driven Development (if I have my way, yes)? Boring Stuff Get a Wiki page going for the project Get a Story Wall setup somewhere easily visible Figure out where we can do standup meetings without irritating the rest of the office Logistics of pairing -- hardware, desk setup, etc. Create a Risk Management list somewhere equally visible A team's definition of "this is the way we do it" will, and probably should, change over time as the team learns and adapts.  It still helps to start with a small core of project conventions and working standards.  Posted Oct 02 2006, 03:10 PM by Jeremy D. Miller with 21 comment(s) Filed under: Starting a new Project