We've (well, really, Finn has for the most part) been adding a lot of features to the app, but I feel like we've moved too fast and now the cost of change is catching up with us. We've got all this code, and it's not very well organized at all--we've got about 40-50% of the essential functionality right now, but getting the next 10% and the next 10% after that and so on is just going to take longer and longer as our code grows (like the yellow line on the graph).
As it stands, I think there's way too much functionality being defined within methods which really needs to be pulled out into objects with designated responsibilities. For example, this method currently handles every bit of behavior associated with selecting a book. The UI specific stuff in the method should stay where it is, but the url parsing and playhead position (as I keep mentioning but still haven't fixed!) code needs to be refactored out.
I guess I've just sort of been swept off my feet with the pace that Finn is adding features. When I'm coding on my own, I tend to go a slower and take a lot of time to think through how to best follow the agile philosophy, so that my productivity can be closer to the purple line on the graph rather than the yellow one. (You can tell I like to take my time, because I've written three blog posts about refactoring the playhead position functionality and still haven't actually done it!)
That's not to say I don't like working on this project or group projects in general: working with others in a codebase is something that is going to be central to any programming job, and I think this is a great experience, since I've never worked directly with someone else on an application before.
This comment has been removed by the author.
ReplyDeleteI'll say it again, I'm delighted with the partnership here developing on this project. You are right in your approach, but you'll have to bring your partner along in order to make the partnership work most effectively. Finn is bright and has that natural urge to drive full speed ahead writing code and solving particular problems as fast as he can. It is only when the time becomes long enough and thus the scale becomes large enough (as your very effective illustration indicates) that the down side to this approach becomes apparent.
ReplyDeleteYoung developers often resist coming to terms with this as long as they possibly can. Using best practices seems like a kill joy and drag and cuts into what they perceive as the fun of what my friend Prof. Reed calls "slinging code." I would argue that there is a more powerful and deeper joy to be had in understanding how best practices can make it possible to handle complexity and to then be able to solve much larger problems effectively.
We should meet on Monday and talk about this. I agree with you, the pace is going much to quickly, so now the time is right to slow down, refactor, get more experienced eyes to look over the project.
You say you don't think unit testing is necessary or feasible. Is that true? Please check on that further at the beginning of the week. Adding unit tests would be a great aid in the refactoring project, because things that are difficult to test often reveal tight couplings in the code that will cause you problems later. Some of these you already alluded to in your post.
If Kevin is willing, it would be great if he could comment on this post as well. I'll ask him.