tag:blogger.com,1999:blog-11788780.post5725296836622438291..comments2023-12-29T13:22:33.104-08:00Comments on JJinuxLand: Agile Programming: I'm Stuck in the Middlejjinuxhttp://www.blogger.com/profile/03270879497119114175noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-11788780.post-90670806017496151952009-08-04T01:57:19.922-07:002009-08-04T01:57:19.922-07:00Thanks for your comment, Adam. It's nice to g...Thanks for your comment, Adam. It's nice to get an update on your thoughts on the matter.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-67013756070467342712009-08-03T09:17:39.495-07:002009-08-03T09:17:39.495-07:00JJ - I'm glad to see more thinking on this (an...JJ - I'm glad to see more thinking on this (and anyone straining against the agile juggernaut.)<br /><br />One thing that I think is funny about TDD is that it seems like it's actually a <em>replacement</em> for just plain thinking for a lot of programmers. My canonical example of this is <a href="http://www.objectmentor.com/resources/articles/xpepisode.htm" rel="nofollow">the whole bowling fiasco</a>. It never fails to crack me up that the classic TDD example is a complete and utter mess -- thousands of lines of code that could be easily replaced by a single function that takes a list of numbers and yields an output. But as the story shows, it's easy and fun to just jump in without even bothering to draw a damn picture on the whiteboard.<br /><br />But I think it's also telling, because the bowling example is undertaken in the absence of any real requirements. When you're handed a problem like this (akin to "provide a web-service that does X") you end up carefully modeling the domain of the real world (separate objects for throws and frames and players) because you don't really know what your code has to do. I think TDD makes developers feel good. They feel more productive than they do just starting at the blank screen. After all, they're writing all this <em>code</em>! (never mind that most of that code tests the underlying library.)<br /><br />Of course TDD, and even more-so, test isolation has its place. I actually think that most of the value from TDD comes from the architecture that it necessitates: the components are loosely coupled enough that they can be tested separately.Adam Wolffhttp://elasticprocess.com/blognoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-48321014286053213842009-07-12T23:34:36.863-07:002009-07-12T23:34:36.863-07:00I think you misunderstood me. The Amazon UI is ho...I think you misunderstood me. The Amazon UI is horrible. It makes me feel uncomfortable and overwhelmed every time I use it ;)jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-79563182373292050272009-07-12T08:39:12.439-07:002009-07-12T08:39:12.439-07:00> Your points are valid, although I still maint...> Your points are valid, although I still maintain that you can tell the<br />> difference between a UI with conceptual integrity (built like a<br />> cathedral) and one without it, <br />Amazon being a great example.<br /><br />I think Amazon makes the case for agile UI development. The amazon site continuously evolves. If it appears to have conceptual integrity at the moment it is because people have worked hard to create or maintain conceptual integrity in the site's current revision. The amazon UI has often been inconsistent and sometimes even broken. The company is truly amazing, highly innovative, and the site is always moving as their business model moves.Unknownhttps://www.blogger.com/profile/00757934952755918929noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-33720330886755504502009-07-11T13:41:47.039-07:002009-07-11T13:41:47.039-07:00Kelly, thanks for the great comment.
> from wh...Kelly, thanks for the great comment.<br /><br />> from what I can tell you are a smart guy and Pivotal would be lucky to have you.<br /><br />Thanks. That's good because I'm going to be keeping Pivotal in mind whenever I need to find another job ;)<br /><br />> I'm a strong believer in agile software development.<br /><br />Actually, so am I. However, I had never yet seen how to do TDD with websites. You helped me overcome that hurdle.<br /><br />> Unlike cathedrals, application requirements change almost continuously to meet ever evolving requirements and changes in technology, business and culture.<br /><br />Your points are valid, although I still maintain that you can tell the difference between a UI with conceptual integrity (built like a cathedral) and one without it, Amazon being a great example.<br /><br />> Comments in *application* code are generally a code *smell*<br /><br />I agree. There's nothing worse than a 150 line function with no docstrings and a bunch of comments.<br /><br />Those aren't the type of comments I use a lot of. I use a lot of API comments. Basically, I add an API comment (aka a docstring) for almost every module, class, and method to give the reader an idea of what they're looking at. That doesn't make sense so much in Rails, but I think it does in other settings.<br /><br />For instance, I remember looking at a codebase that had three files named autocomplete. I had no clue why there were three, and if all three were used. It turned out that one was the webservice entry point, one was for talking to the database-based autocomplete service, and the other was for talking to the Lucene-based autocomplete service. A one line comment at the top of each file would have made my life much easier.<br /><br />Anyway, thanks for all your feedback. I'm going to give it a shot and see how it turns out ;)jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-72867874985003335552009-07-11T13:11:02.007-07:002009-07-11T13:11:02.007-07:00JJ,
Thanks for the great article.
First, let me c...JJ,<br /><br />Thanks for the great article.<br />First, let me clarify: I was trying to make a point about test driven development and comments in code -- from what I can tell you are a smart guy and Pivotal would be lucky to have you. <br /><br />I'm a strong believer in agile software development. I know XP is not right for all software projects but I do think it is right for the majority of what I do today, which is building web and mobile applications.<br /><br />Your cathedral analogy is useful. Some cathedrals took more than a hundred years to build. A plan is necessary to make that happen. Keep in mind that some cathedrals had design changes before the building was complete. Once complete a cathedral is relatively static for hundreds of years.<br /><br />Unlike cathedrals, application requirements change almost continuously to meet ever evolving requirements and changes in technology, business and culture. Few applications will be around for more than, say, 10 years. And far too many never go into production.<br /><br />Agile practices attempt to improve on the software practices that cause software projects to fail or lead to inflexible software that cannot evolve as the requirements change.<br /><br />Automated testing is one of those practices. Automated test suites allow you to change your code with confidence. Without an automated test suite code becomes brittle while development schedules and testing personnel expand. You eventually reach the point where you can't afford to change it. Then, if anyone still cares about the application, the answer becomes "Let's rewrite it". <br /><br />Comments in *application* code are generally a code *smell* -- it's a sign that the code is obtuse, and if it's obtuse it should probably be changed.<br /><br />Commenting a public API is another thing altogether. An API is a contract and you need to be careful when changing that contract. Providing documentation on that contract helps consumers of that API get their work done. <br /><br />It's cool to be discussing these issues. My opinions are constantly moving and have moved a great distance since I've been at Pivotal and practicing XP every day.Unknownhttps://www.blogger.com/profile/00757934952755918929noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-7963485309615744852009-07-10T11:49:37.768-07:002009-07-10T11:49:37.768-07:00Florian, great comment!
I think your style of dev...Florian, great comment!<br /><br />I think your style of development matches Titus Brown's approach to testing. I think he calls it stupid testing or something like that. He adds tests for code that has proven it needs it. Titus is a total test buff who has to cope with legacy systems, so he has room to argue.<br /><br />I agree that testing and designing up front doesn't prevent bugs. Most of my bugs come from situations that I never even thought of. Hence, neither the code nor the tests addressed those situations. A TDD person would say that once you find a bug, you should write a test for it, and once you fix a bug, your existing tests keep you from breaking something else. It's a useful viewpoint, even more so if you have to fix someone else's bugs, and they haven't written any tests.<br /><br />I think I'd like to be like Knuth with TeX. Once you find a bug, the author owes you an ever-increasing amount of money ;)<br /><br />I also agree with your sentiments which I like to call "fail fast" and "plan for debugging". There's nothing worse than code that results in nil, NULL, or None in places where it shouldn't be, and then some other, innocent part of the code crashes. I also hate it when things crash, and I'm left with absolutely no leverage to fix the problem.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-24546766269613617122009-07-10T11:40:32.223-07:002009-07-10T11:40:32.223-07:00> The construction of Notre Dame may have been ...> The construction of Notre Dame may have been more agile than you think. According to Wikipedia, it took almost 200 years to build and "over the construction period, numerous architects worked on the site, as is evidenced by the differing styles at different heights of the west front and towers."<br /><br />Nice comment! Perhaps the differing styles is proof that an agile design leads to lack of conceptual integrity? Perhaps this wasn't the case with other cathedrals?jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-56477974580633454662009-07-10T08:15:44.442-07:002009-07-10T08:15:44.442-07:00I often feel like the whole TDD/Doctest/Up Front d...I often feel like the whole TDD/Doctest/Up Front design etc. debate in regards to making bug-free software is slightly off-topic.<br /><br />One of the things I see even in well tested life systems is that no amount of coverage, no number of tests, no documentation and certainly no amount of up-front design is able to prevent bugs from creeping in.<br /><br />The bugs you discover after you've done all you could to produce solid software are usually those which make most of the maintenance efford.<br /><br />I've come to practise a style of programming that: 1) makes any error noisy 2) logs away contextual data relevant to reproduce errors (such as inputs etc.)<br /><br />When an error happens in a system of mine, I have an easy time tracking it down and writing a test for it much more often then simply relying on a suite of pre-fabricated tests that do not cover that error.<br /><br />It's not really TDD, though tests are involved, but only post-mortem. However I find that this is faster then a large efford in up-front Tests and Design to erradicate bugs. I Design to squash bugs fast and painlessly in operation.Florianhttps://www.blogger.com/profile/06798512674087485252noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-78867360883927941192009-07-10T03:56:27.238-07:002009-07-10T03:56:27.238-07:00The construction of Notre Dame may have been more ...The construction of Notre Dame may have been more agile than you think. According to Wikipedia, it took almost 200 years to build and "over the construction period, numerous architects worked on the site, as is evidenced by the differing styles at different heights of the west front and towers."Kent Johnsonhttps://www.blogger.com/profile/07551184180475198771noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-10555739446918141272009-07-10T00:16:09.081-07:002009-07-10T00:16:09.081-07:00Is it just me, or does Cucumber remind you of Prol...Is it just me, or does Cucumber remind you of Prolog. I wonder if it's possible to use a Prolog-like logic language to drive Cucumber-like tests.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-82755345765271181112009-07-09T23:18:08.148-07:002009-07-09T23:18:08.148-07:00By the way, Kelly said he prefers Cucumber over th...By the way, Kelly said he prefers Cucumber over the integration testing that Rails has built-in. Cucumber can run Webrat which can use Selenium, Watir, etc.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-82987155728276766062009-07-09T22:53:17.358-07:002009-07-09T22:53:17.358-07:00Good conversation. Thanks.Good conversation. Thanks.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-32330146205121070762009-07-09T22:00:20.622-07:002009-07-09T22:00:20.622-07:00Hi Shannon,
I'm *sure* pivotal are agile. I u...Hi Shannon,<br /><br />I'm *sure* pivotal are agile. I use Pivotal Tracker and really like it, too. ;-)<br /><br />But for *their use cases* documentation may just not be deemed valuable enough. So they're making the right choice for their use case. That doesn't mean you can't do TDD, follow "agile" principles, and still have good documentation.<br /><br />Maybe I should temper my comment though: I've never been able to make TDD of the UI work. I've seen a lot of developers write a lot of Selenium tests, trying to guess in their minds what the output HTML will look like, and then having to rewrite their tests again and again because they are very brittle. I'm sure there are better ways (like testing mockups), but I don't see the greatest cost/benefit tradeoff in UI TDD. I see a much better cost/benefit ratio for TDD of business logic functions.<br /><br />Clearly, there is a risk of over-engineering. To me, you're agile if you're doing the right amount of design for your project. Progress in an agile project is measured in terms of business value delivered, and there's no intrinsict business value in a big design document. Design in models, mock-ups and the like will often be more appropriate since they are (a) more easily changed if required and (b) a lot less work to produce and maintain.<br /><br />MartinMartin Aspelihttps://www.blogger.com/profile/11251335463579376973noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-60104291813738024972009-07-09T20:30:24.770-07:002009-07-09T20:30:24.770-07:00> Crucially, it's not an excuse for skimpin...> Crucially, it's not an excuse for skimping on documentation or design, and it doesn't dictate that things have to be done piecemeal.<br /><br />Martin, thanks for your comment. It very much matches what I thought before Kelly sat me down and gave me a talkin' too.<br /><br />I'd hesitate to say that Pivotal isn't an agile company. They do TDD, peer programming, some version of Scrum (I think), etc. I definitely don't know of any company that is *more* agile than they are.<br /><br />However, they seemed to be the ones who objected most to my excess of documentation. Kelly was definitely advocating against designing too much up front because he said it lead to overengineering.<br /><br />He preferred to describe a requirement using a testing tool like Cucumber and then attack that test as directly as possible.<br /><br />You said, "doing TDD at the UI level (e.g. with Selenium/Windmill) seems utter madness to me," but that's exactly what Kelly was advocating for. Clearly, there's a divide between the two points of view.<br /><br />By the way, I don't think Kelly would be against some real user testing. After all, I never have figured out how to write a test that says, "This UI must not be ugly."jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-64594132428142463712009-07-09T20:21:29.327-07:002009-07-09T20:21:29.327-07:00Great points, Juergen.Great points, Juergen.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-73568137060368312592009-07-09T19:21:05.605-07:002009-07-09T19:21:05.605-07:00The word "agile" is tricky, because so m...The word "agile" is tricky, because so many people mean so many different things by it, and even more people who've never done an "agile" project, *assume* so much about it.<br /><br />To me, "agile" is a set of principles and values that say something about how to deliver good software projects for customers. It's about focusing on delivering value and quality, in a world where some traditional techniques adopted from other disciplines have proven ill-suited to the rather messy world of software development.<br /><br />Crucially, it's not an excuse for skimping on documentation or design, and it doesn't dictate that things have to be done piecemeal. Some people who claim to be doing agile projects do that, but that's only a valid approach if it is the most appropriate thing for the project (e.g. the customer doesn't value a highly consistent UI, or this is a rapid prototype).<br /><br />You're agile if you apply the *right* amount of design for the project, and if your designs and plans are malleable enough to be able to absorb change in requirements and external factors.<br /><br />I think Juergen is right that agile works best in environments with a clear vision. I'd add it also works best if you have "good" programmers who can think for themselves and bring valuable insight or opinions to the frequent discussions that tend to take place in agile projects. With a team that is less experienced (or with outsourced 'commodity' programming resources), you need to adopt a lot more structure and a more waterfall-like approach. That dosen't mean you can't be agile, but it does mean your process has to change if you're used to managing co-located, small, highly skilled teams.<br /><br />TDD is an approach that is often employed in agile projects. Not all TDD projects are agile and not all agile projects use TDD. It's quite an interesting and good technique. In my experience, it works well when you're writing small components against a dedicated API. Doing TDD at the UI level (e.g. with Selenium/Windmill) seems utter madness to me, though. There's simply no way that can replace doing proper UI design and human click testing. Having some integration tests that drive the UI is often valuable, but not as a substitute.<br /><br />I also fully agree with your approach to write docstrings first, and refactor them with the code. Good documentation is hugely important, and saying that the code is self-documenting or the tests document the code is an excuse used by pepole who don't read other people's code.<br /><br />MartinMartin Aspelihttps://www.blogger.com/profile/11251335463579376973noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-55920074264493888922009-07-09T18:32:29.520-07:002009-07-09T18:32:29.520-07:00Good article and observations. I also feel that Ag...Good article and observations. I also feel that Agile is suitable for some, but not all projects. The good UI as well as the memory manager are good examples.<br /><br />I believe that Agile works best in environments where all developers are clear on the overall vision and direction the project has to take and we are just in the process of adding more features.<br /><br />However, you need a more unified big-picture approach for things like the UI, but also consistent error handling and other less visible aspects of the system. Design those in a more traditional, up-front manner, and allow a more Agile approach to adding the various features once these things are settled on.<br /><br />Agile for architecture development is less suitable than for just feature addition. If you work only in frameworks such as Django or Rails then you don't need to worry much about the architecture side of things, since that's pretty much dictated to you. For non framework-based apps, though, I'd be hesitant to go with Agile from the beginning.Juergen Brendelhttp://www.brendel.com/consultingnoreply@blogger.comtag:blogger.com,1999:blog-11788780.post-68158665101445502852009-07-09T16:13:30.280-07:002009-07-09T16:13:30.280-07:00This video is a trip: http://media.railscasts.com/...This video is a trip: http://media.railscasts.com/videos/155_beginning_with_cucumber.mov<br /><br />Cucumber lets you write your tests in pseudo-English. Since Cucumber tests are executable, but they are also readable by non-engineers, I can see how they might be move valuable than normal docstrings.jjinuxhttps://www.blogger.com/profile/03270879497119114175noreply@blogger.comtag:blogger.com,1999:blog-11788780.post-46302348024158973632009-07-09T16:09:23.391-07:002009-07-09T16:09:23.391-07:00> I suggest some mix of Twill, Nose, and Seleni...> I suggest some mix of Twill, Nose, and Selenium<br /><br />I think, Windmill would be a better choice than Selenium. And I also recommend tddspry, if you use django.Sergey Kishchenkohttps://www.blogger.com/profile/13451038740185023562noreply@blogger.com