<br><div class="gmail_quote">On Thu, Feb 28, 2008 at 2:22 PM, Glenn Ford <<a href="mailto:glenn@aldenta.com">glenn@aldenta.com</a>> wrote:<br><br>I agree with David - you are certainly on the right track. I also think
you are doing the right thing when you write specs even if they seem
not perfect to you at first attempt - once you have written the code
you can evaluate why they could be better and then make your
adjustments as you learn more.<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A lot of times if I'm writing some code for a challenging piece, it's<br>
challenging to me because I don't already know how to do it. I can<br>
write the basic "here's the setup, result.should eql(this_thing)" but<br>
I can't write any mocks/stubs/should_receives in the middle because at<br>
every step, I just honestly have no idea how it should work!! So I<br>
throw in real models and try to make it as real as possible, rather<br>
than as "pure" as possible. It's not until after I get things working<br>
that I even know what the solution should remotely look like. This is<br>
due to my inexperience that I have to hack around a lot before I<br>
figure out how to make things work. Unfortunately, I know this means<br>
I write code that is more complicated than it should be, but if I<br>
can't figure out a better way, I have to write something that still<br>
works!</blockquote><div><br><br>I also often find it hard to implement a new solution from scratch using the BDD / TDD test-first approach. Sometimes it works for me to make a very crude spike solution to figure out how this part of the program actually should work (often writing no automated tests at all). Once I have an idea of the outline I put the spike away and start implementing the real solution in the real codebase, writing tests first etc.<br>
<br>Interestingly, it seems to me that the whole task actually _is_ accomplished quicker this way because I don't have to keep the production code clean & tested while experimenting and because I don't have to sit and figure out the design while writing the production code.<br>
<br>As a gain experience I think there will be more solutions that I can implement without having to spike them before.<br><br> -- Siemen</div></div>