chris clarke
software development that works…or something
Retrospective: Storyboard
January 11, 2007 on 10:51 pm | In Retrospectives |In order to come up with some working practices for Storyboard 2 - I’m going to hold a quick retrospective of Storyboard 1 right here - a Blog-o-spective.
What went well?
- Easy to use
- Fun look and feel
- Easy to deploy
- Quick initial development
- Introduction of XML
What did we learn?
- Ajax apps are hard to test
- Having output not being logged or logged to different places is bad
- Integration tests between python and javascript are hard to write
- Tests between front and back-end are definitely needed
- Development is easiest when tests are easy to write and can drive features
- Too much client-side processing in javascript slows things down (duh?)
- Writing ajax stuff without a library is very fragile
- There’s plenty of libraries/frameworks for both Ajax and DHTML stuff.
- Storyboard without a zoom feature or different views is not useful because you can’t see all the cards easily.
- Building cross-browser compatibility from the start would have been much easier
- In fact a lot of things could have been much easier if they had been done from the start especially logging & integration tests
What should we do differently next time?
- Need a framework/way of writing tests quickly and easily e.g. Google Web Toolkit
- Make more use of ready-made libraries e.g. YUI
- Maybe use something other than python for back-end
- Have better test coverage - back, front and integration
- Prioritize features e.g. zoom feature should be high prioirity
- Have an agreed set of practices/prejudices from the start e.g. Log to one file
What still puzzles us?
- Why I did things differently than I would have done in a pure Java project e.g. no TDD from start
- Why CGI and Ajax stuff can just go wrong but not tell you why
- Why there aren’t more standard or popular libraries for JavaScript
Some Storyboard Working Practices
- Progress will be measured in running tested features. Features will be documented via the test code. The progress will be displayed on a infinite burn-up chart.
- All ideas & feature suggestions will be recorded and prioritized in a backlog.
- No code shall be written without first searching for some code which does what is needed easily.
- Any relevant output, logging or debugging information will be appended to one file: The Log.
- Test driven development.
- For a piece of code to be considered done done it will be Tested, Refactored & Integrated. (Refactored practices: No methods > 10 lines. No classes that break the scrolling rule (~40 lines in Eclipse).)
1 Comment »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Retrospective: Storyboard
January 11, 2007 on 10:51 pm | In Retrospectives |In order to come up with some working practices for Storyboard 2 - I’m going to hold a quick retrospective of Storyboard 1 right here - a Blog-o-spective.
What went well?
- Easy to use
- Fun look and feel
- Easy to deploy
- Quick initial development
- Introduction of XML
What did we learn?
- Ajax apps are hard to test
- Having output not being logged or logged to different places is bad
- Integration tests between python and javascript are hard to write
- Tests between front and back-end are definitely needed
- Development is easiest when tests are easy to write and can drive features
- Too much client-side processing in javascript slows things down (duh?)
- Writing ajax stuff without a library is very fragile
- There’s plenty of libraries/frameworks for both Ajax and DHTML stuff.
- Storyboard without a zoom feature or different views is not useful because you can’t see all the cards easily.
- Building cross-browser compatibility from the start would have been much easier
- In fact a lot of things could have been much easier if they had been done from the start especially logging & integration tests
What should we do differently next time?
- Need a framework/way of writing tests quickly and easily e.g. Google Web Toolkit
- Make more use of ready-made libraries e.g. YUI
- Maybe use something other than python for back-end
- Have better test coverage - back, front and integration
- Prioritize features e.g. zoom feature should be high prioirity
- Have an agreed set of practices/prejudices from the start e.g. Log to one file
What still puzzles us?
- Why I did things differently than I would have done in a pure Java project e.g. no TDD from start
- Why CGI and Ajax stuff can just go wrong but not tell you why
- Why there aren’t more standard or popular libraries for JavaScript
Some Storyboard Working Practices
- Progress will be measured in running tested features. Features will be documented via the test code. The progress will be displayed on a infinite burn-up chart.
- All ideas & feature suggestions will be recorded and prioritized in a backlog.
- No code shall be written without first searching for some code which does what is needed easily.
- Any relevant output, logging or debugging information will be appended to one file: The Log.
- Test driven development.
- For a piece of code to be considered done done it will be Tested, Refactored & Integrated. (Refactored practices: No methods > 10 lines. No classes that break the scrolling rule (~40 lines in Eclipse).)
1 Comment »
RSS feed for comments on this post. TrackBack URI
-
[…] Looking around for AJAX libraries to use for storyboard following a retrospective around the initial development, I stumbled across scriptaculous, one of the benefits being that it has it’s own unit test library. An alternative may be to use jsUnit which has syntax much more familiar to anyone who’s ever used JUnit. […]
Pingback by chris clarke » Unit Tests In Javascript — February 2, 2007 #
Leave a comment
Powered by Cheese.
RSS Entries Feed.
RSS Comments Feed
^Top^
[…] Looking around for AJAX libraries to use for storyboard following a retrospective around the initial development, I stumbled across scriptaculous, one of the benefits being that it has it’s own unit test library. An alternative may be to use jsUnit which has syntax much more familiar to anyone who’s ever used JUnit. […]
Pingback by chris clarke » Unit Tests In Javascript — February 2, 2007 #