This course, while definitely enjoyable, has been somewhat stressful for me. We're undertaking a huge task. No one ever thinks about how much work goes into making a finished product (for anything, really, let alone a computer program). For one example, we (we as in the CS students) don't like having to tell everyone else that the Artifact class has changed again. Some times it's changed because we're told there's something that isn't there that needs to be, or there's something in there that's just superfluous information. Sometimes the decisions are ours, others they're not. Even now with the last week of class, there's still a lot of work we have to do. And while I know I'll be able to look back and see what we've accomplished, I know there will be things that we wanted to have in there but just ran out of time to implement.
Since we've had so little time, overall, to work on this, I think we've taken to heart too much of this infamous CS quote: "Weeks of programming can save you hours of planning." I think we've been too eager to just jump in and click-clack away at the keyboard to meet our deadline, where if we had taken more time getting the specifics down we would be better off now. Dr. Gestwicki looked over my shoulder at some code I'd written and said something along the lines of "don't you feel bad for writing that?" And honestly, yes, I did a bit--but it does exactly what it's intended to do and works how it's supposed to. Could I have made it look prettier? Most definitely. Could I have done it a better way? Yup, could've done that, too.
At what point does "good" overwrite "functionality"? If something is working as it's supposed to, and does what's it's intended to do, is it worth the time and effort to change when something new can be done in that same time? I'm reminded of that first article we read at the start of class where they were developing playable games in one week and we were told (I'm paraphrasing/rephrasing from memory here) that "it doesn't have to look pretty as long as it works."
These questions are all rhetorical and these points have already been talked out, but those are just some thoughts floating around in my head.
When you have a chance, you should read The Pragmatic Programmer. It's an excellent book, and it addresses several of the points you make above.
ReplyDeleteOne of the laws of production software (as opposed to assignments) is that it always lives longer than you expect it to. Consider Morgan's Raid: how many times did we consider that to be done already, and it only shipped a few weeks ago?
In my opinion, there are precious few cases where good design is not worthwhile. The practices you reinforce become your habits.
But you don't have to take my word for it. Robert "Uncle Bob" Martin, on the title page of Clean Code, says:
ReplyDelete"Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best."
I just started reading this book, and I'm already in love with it.
I've been working on a Android app that involves databases and list views and such. As I was coding the first version of it I kept realizing I was repeating and repeating and repeating myself. It was terribly long and tedious. Finally, I finished the main functionality I wanted but the app was 184kb. That only consisted of 3 databases and 11 classes.
ReplyDeleteSo I went back to the drawing board, quite literately. I grab a pencil and paper and started drawing out the functionality of the program. Then a light bulb turned on in my head. Instead of repeating myself 100 times making a method inside every class, I can design a utility class to perform the methods I need. It works surprising similar to the ExplodingLoader class in Morgan's Raid.
After this change, the total space the app took was only 63kb. Much better than the 184kb. During my first hack of the program I was being to hasty and not thinking just doing. It felt wrong but I didn't want to stop. When I was done with it, yeah I had the program doing what I wanted, but I wasn't satisfied.
Last comment about Clean Code, I swear.
ReplyDeleteOne of the things in the book that surprised me was how much effort Martin spends talking about writing short methods. His version of short makes mine look epic. I started writing some code following his advice, and it was excellent.
The bigger point is that, in agile, "done" is not "done" unless you've refactored. DJ's story is a great example: it wasn't enough to leave it ugly, when a professional should take the time to make it clean.