0

I'm starting project number 8,192. Like most of my projects, they are either throw-away projects or projects that get canceled either from boredom, time or lack of usefulness.

But there is a project that has been on the back-burners for a long time that I really want to finish. In my perfect world mind, it should take 3 months for first release.

Anyway, one of my biggest issues is taking a large project (or even a small to medium one) and break it down into manageable pieces. My error is to always jump right on the terminal, open Textmate and start coding. This almost always fails. I get lost in feature creep, learning newer methods, framework wars, etc. Then, two months have gone by and nothing to show for it.

So I was thinking if BDD (such as Cucumber) might be a solution to this? Could it be used to scope out the larger pieces, then the smaller pieces until I have a feature list that is most of the project. At that point, I just start coding the pieces right?

What are your suggestions on tackling this problem that I'm sure other developers share.

BTW, I'm using Rails 3 (sometimes Padrino).

Thanks

cbmeeks
  • 11,248
  • 22
  • 85
  • 136
  • Discipline, not development methodologies, stops feature creep. – Dave Newton May 01 '12 at 18:59
  • I agree 100%. But, in my best ninja voice, `I lack disipline!`. lol. Seriously, I'm looking for better ways to keep me on track so that I become MORE disciplined through better processes and procedures. – cbmeeks May 01 '12 at 20:28
  • (Moved to answer so I can use paragraphs. It's not an answer, though.) – Dave Newton May 01 '12 at 20:52

1 Answers1

1

On which track? BDD doesn't define the track--it communicates the track.

BDD may be the only requirements you have (or need), but that doesn't address the issue of feeping creaturisms unless you have the discipline not to implement anything for which no spec exists.

Uncaptured features don't get implemented, period. If a feature is added, it gets a scope, and is prioritized with the rest of the features. It may usurp something less-desirable, it may not.

The product owner (you in this case) must decide how much can be implemented in the time allotted, and which features should be implemented. Still boils down to discipline, however, you just have a tool that (helps) make sure what you implemented is what you actually wanted.

It doesn't, however, make sure that what you get is only what you originally wanted--it won't make sure nothing else is implemented on top of the specs you bothered to implement.

Dave Newton
  • 158,873
  • 26
  • 254
  • 302