Today's assignment is MyISERN-1.1.
All assigned tasks completed.
Difficulties
The main difficulty was figuring out how to design the program and organize ourselves. My parter Kevin English has a lot of experience with MVC using Ruby on Rails, so we decided to use an MVC design. Kevin worked on the controller and the view, and I worked on the model.
We were also a little unsure about how the model should look. We started writing out method calls showing how it would be used, and then we though maybe we should try test-driven design. So, for the model at least, I was using TDD.
I came up with a technique of commenting out the @Test annotation (as //TODO @Test) and using Eclipse to generate stub implementations so that I could check in the unit tests before the "real" code without breaking verify. It worked fairly well -- writing the code seemed to go a lot faster with the tests in place1.
The biggest problem as far as organizing the group was the model interface. I think we spent most of two meetings talking about what the method signatures would be. Finally, it was all settled. Then right after the last meeting before release, I got an email from my partner telling me I had done it wrong.
Next Time
Next time, I'd like to nail down all the interfaces between code that will be written by different people before anything else is done. It might help to print out the Javadoc HTML and bring it to the meetings.
We seemed to be meeting more as time went on. I guess it helps more than we expected.
I wouldn't mind using TDD again, but I really think it's time to add a web interface and a database. It gets harder and harder to add those as the project gets on. I don't care how agile you think you are, this is a huge risk. It's like we're deliberately simulating the type of insane requirements flux that kills projects2.
I wrote our current data model, and I know that it will have to be thrown away when we go from JAXB objects to a database. Obviously, the same is true for my partner's command-line and text table code when we go to the web.
Why didn't we write an abstraction layer so that we can easily switch? Doing that so it actually works is a lot harder than it sounds. I doubt anyone has had enough time to even come close.
(I just saw Kevin's entry. I agree, it's also time to ditch Java.)
2 comments:
Hi Brian,
It's definitely not deliberate. I am making this project 'incremental' so that people have time to master certain skills before being confronted with new ones. If you're already very experienced with Ruby on Rails, backend databases, and MVC, then you're far ahead of most people in the class (at this point in the semester, anyway. :-)
On the other hand, this project is not an example of 'insane requirements change'. Many real world projects get "repurposed" far more than this one will, and so you are not dealing with anything exceptional.
Having an in-memory data structure that is independent from a persistency layer is a very reasonable design choice in this domain, particularly because of the "network" nature of the information, and because the entire social network will fit in memory (as I noted in a previous posting). Thus, if you work on refactoring and thinking through your design with each increment, you should find that more and more of your code can be reused as new requirements come up.
Good insights, keep them up!
Well, it's Kevin who knows Rails and MVC. I've never used Rails, though I've done things that could be considered MVC. I have done quite a bit of database work.
I don't know how common it is to switch from a console interface and XML back-end to a web interface and database back-end halfway through the project. I do know that it's a bad idea, and no level of commonality is going to change my mind about that. Remember, project failure is also common.
Besides, the fact that something bad can never be eliminated is no excuse for knowingly and unnecessarily adding more of it.
I like iterative development, but I don't believe that iterative development -- or any other workable style of development -- tells you to knowingly spend time on non-trivial features that don't satisfy requirements. Planning for change means you treat your goals as tentative, not that you deliberately move away from them.
If you know that the final product needs to be a web site backed by a database, the first iteration should be a web site that at least touches a database (even a small in-memory database). You don't want to integrate at the end, and you don't want to choose the data model at the end.
Post a Comment