Editor’s note: This is a guest post by Starr Horne, creator of ChatSpring, a live-chat application. You can read more by Starr at Upstarter – the simple habits of successful entrepreneurs.
I love deadlines. I like the whooshing sound they make as they fly by.
- Douglas Adams
Freedom! There’s nothing like a new project. Finally – you get to do things the RIGHT way. To use your favorite language and the best framework. To write an app that’s a beauty to behold, both inside and out.
And that, my friend, is where it all goes wrong.
Without constraints to guide us, it’s all too easy to veer off course and wind up in one of the thousands of ditches that line the road to beta.
Boy, did I learn it the hard way. Let me give you a little tour of the time-sucks I encountered while developing ChatSpring.
1) Waiting for the perfect idea
There’s not one.
Donald Trump. Bill Gates. Larry Ellison. Even with all their experience, these guys can’t pluck a market from thin air, design a business and implement it without a few iterations.
So why should you? At some point you just have to jump in.
2) Choosing the WRONG tool for the job
Tell me again, why are you writing a window’s GUI app in lisp? Sure, you can. But you can also run the Kentucky Derby with a camel.
The problem with a lot of the most powerful tools is that you can adapt them to your problem. But it will take so much time and deplete so much of your sanity that you would have been better off just holding your nose and using C#.
3) Imaginary Yak Shaving
Thou shall not build frameworks or miscellaneous libraries. Is that too overdramatic?
Look – the problem with frameworks is that by nature they’re general. But your application is specific.
So by building frameworks or libraries, you have to write a lot more code to cover a lot of use cases, which have nothing to do with your application!
4) Too detailed too soon
Test Driven Development is like Grammar Driven Literature.
The great thing about tests is that they freeze your functionality in time. But that’s the last thing to do if you expect to make major architectural changes (and you should).
Instead, wait to create your tests, style your pages, and document your code until after you have the whole application roughed in.
Otherwise you risk spending a lot of time on code that you end up throwing away.
5) The kitchen sink syndrome
You should have V1 done in 6 months. If you’re application’s too big to complete in that time, scale it down.
Your beta testers won’t be shy about asking for extra features. And their ideas can be pretty good.
What have we learned?
Let’s be honest here – the longer you drag out development, the smaller the chance that you’ll ever release. But by avoiding these five dead ends, you’re 100% guaranteed to become as rich as Larry Page. No? Well – you’ll be one step closer.
What do you think? What have been YOUR biggest time-wasters?
Popularity: 11% [?]
{ 1 trackback }
{ 16 comments }
I agree in principle with each of your points, except that there are occassions where Yak Shaving can assist if and only if the time expended can be justified in overall development and maintencance, you’ve had a bit of experience writing efficient libraries and they will be re-used and there is no other practical way to implement. Otherwise buying them if available makes good practical, economic and time saving sense.
Staying focused is very hard. There’s too much out there to learn about that’s too distracting. I spent 4 months learning the new CSS standards and changing my website design, setting up WordPress to replace my blog, bbPress to replace my Forum, and learning PHP to customize WordPress and bbPress to my liking.
That’s 4 months I didn’t work on my program. Although my website did need a new design, my blog and forum were doing the job they were meant to.
Although I agree with your second point, I couldn’t help but smile when reading your example. I am actually selling a mac application whose GUI is written mainly in lisp. This makes me so much productive, I would never do otherwise if I had to start over.
I will also emphasize your point about having beta testers. Getting beta testers early is a good thing not only for the great ideas they can provide, but it helps a lot in keeping the motivation, and remaining focused.
@Scott – Good point, there are exceptions to every rule. Sometimes it is just faster/easier/cheaper to write the darn thing yourself. For ChatSpring I wound up writing my own queue server. The OSS alternatives were way too complex, but you can create one in python/twisted with ~50 LOC.
@Louis – It *is* tough to stay focused, because learning new things is half the fun of development. (At least for me). And personally, I tend to start little technical “side quests” when I’m trying to avoid something harder (like marketing). I guess we all just have to learn to work around our own bad habits.
I agree with all your points, but extremely strongly disagree with 4).
The right time for TDD is right now. *Especially* if you expect to have major changes coming in.
Your tests need to be written at the right level, to be testing the right stuff, but diving into a major project nowadays without writing robust tests as you go along is just really bad practice that will really, really hurt you not in the long or medium term but even next week – long before you release your beta.
If you do major refactorings, certainly some of your tests will break. And there, the difference between having tests and not having tests will be the difference between knowing what actually broke in this refactoring and not knowing. That can make the difference between that refactoring taking an afternoon or it taking two weeks of trial-and-error.
TDD, like many agile practices, is especially useful when there’s a lot of change ahead. Don’t skimp on it.
Daniel
PS: By “TDD” I mean writing automated tests, generally up front, before writing code. Quite acceptable to work out a bit of code without writing tests immediately if it’s quite complex and you need to figure out how to do it first, but the tests shouldn’t be far behind.
Could not agree more. However, regarding your first point, I find that it’s easier to develop an idea or a concept when you’re constantly writing about it in a dedicated notebook every day. Generally, people start because they have something at the tip of their tongue, and they just don’t know how to say it perfectly. Plus, it lets you engineer the idea inside and out.
While I understand the thinking behind “too detailed too soon,” I strongly believe that if you wait until later to build your tests, that you won’t build them at all, or only incompletely. Building tests for code that may one day reside in the bit bucket certainly is costly and time consuming.
I would suggest that you have a good set of user interaction stories that encompass the application you are creating – particularly stories that flex the edge cases, and create tests (or test scripts) for those. Having a set of “sanity tests” that were created around the idea will be invaluable when you are racing to meet a deadline and have been so mired in details that you may have lost your sense of direction.
Mostly sound but the knock on TDD is misplaced. You seem willing to throw a way code but not tests. Is that the fault of the tests?
And there’s a difference between changing functionality and changing architecture. In fact if you want to change the architecture but keep the functionality you’re really really going to want to have those tests.
A lot of people, including the author of the article, form opinions about TDD out of ignorance.
You (the author) are simply unclear on the concept. TDD does not freeze your architecture; in fact, it does the opposite. It gives you the confidence (not just a gleam in your eye, but real, mechanized proof) that even huge changes done at any step in the project can be done without hesitation and with minimized risk. This is why TDD is a cornerstone of agility.
There are other misunderstandings about TDD that you probably also have if you didn’t get that one, but I think that’s the most important one.
“Test Driven Development is like Grammar Driven Literature”
I have a love/hate relationship with TDD, so depending on the day of the week, I may totally agree with this or totally disagree with it. Either way, it’s an amazing turn of phrase! You’re a poet. Awesome.
I cannot tell you how frustrating it is to see software never get released. I’ve been attached to projects that had literally every idea a team thought of added into it. Three years later…
I agree with all your points, aside from #4. The thing about writing automated tests is you’re trading the time it would take to manually test a feature vs the time to write the automated test for it.
A simple or rarely changing feature may not need any automated tests after you initially verify it works manually. In other cases, the process may require alot of time to manually verify, or may require continual manual testing as the app evolves, so an automated test may be warranted.
When in doubt I tend to write the tests, and evolve them with the feature, knowing in some cases I may need to throw out some testing code, which is fine, because at least overall I’m making the best use of my time.
“Tell me again, why are you writing a window’s GUI app in lisp? Sure, you can. But you can also run the Kentucky Derby with a camel.”
Because it allows abstraction on axes that simply aren’t possible in C#, and I’d rather spend my time building more powerful tools and libraries than trying to figure out how to work around C#’s intentional limitations. Your analogy is backwards here: if everybody else is running the Kentucky Derby with a camel, would you use one too?
“The problem with a lot of the most powerful tools is that you can adapt them to your problem. But it will take so much time and deplete so much of your sanity that you would have been better off just holding your nose and using C#.”
I don’t see the connection here. How would using more powerful tools deplete your sanity? And aren’t camels the smelly ones?
“Test Driven Development is like Grammar Driven Literature.”
Bad analogies are like thunderstorms.
“The great thing about tests is that they freeze your functionality in time. But that’s the last thing to do if you expect to make major architectural changes (and you should).”
If you’re making major architectural (or any other) changes, you do want to freeze functionality: everything except what you’re changing right now.
“Instead, wait to create your tests, style your pages, and document your code until after you have the whole application roughed in. Otherwise you risk spending a lot of time on code that you end up throwing away.”
Yes, that would be awful. It would be like a doctor spending a lot of time on a patient who’s going to die anyway.
Ha! I knew that the TDD remark would turn some heads.
By no means did I want to disparage TDD. If you’re the type of developer who can write a detailed spec and then code it top to bottom, then it may make a lot of sense to write the tests upfront. But I have to work in a more iterative way, and I’ve had to throw away whole test suites when it became clear that I’d written code that did the wrong thing, perfectly.
These are some excellent tips!
Too detailed too soon speaks to me as does the building libraries one.
TDD is NOT about writing a spec and coding it “top to bottom”, nor is it about writing your tests up front. TDD is about making sure that the design you have NOW actually works. It is also about helping you evolve your design. TDD is iterative and incremental. You should only ever have one failing test: the one test you’ve just written for the feature you’re just about to add.
Jim Shore and Shane Warden have a good description in “The Art of Agile Development”. They have the steps of TDD as:
Think
Write a test and watch if fail
Make the test pass
Refactor
Repeat
You do a little bit of design immediately before you write a test, and improve the whole design once your test is passing. I use TDD all the time, because it helps me to design my applications better, and ensure that what I’ve done actually works. If I need to change my mind about something, it’s easy to remove the tests that don’t apply any more and then develop new code and write new tests (using TDD) for how it’s now supposed to work.
Throwing away test suites is no worse than throwing away code.
Comments on this entry are closed.