I have ran into a few snags while trying to update parts of my code that depended on other peoples’ code. Other people updated the interface of their modules, and I needed to update the way my module interacted with theirs. Being slightly optimistic and feeling a bit of schedule pressure, a simple identifier substitution with an occasional update of data type seemed sufficient for the task without actually employing some refactoring techniques.
I was lucky enough to be able to tighten my development cycle. In particular, I was able to jump into testing very early in the implementation of the module. With the use of an automated test tool such as JUnit, the functionality of a module can be continually tested as the module is being developed. The automated test tool is also useful in ensuring that the expected behavior does not change while performing a refactoring such as modifying entity names within a module.
I acted to apply the changes as quickly as it was known to me that an update needed to be done. This resulted in an instance of a big bang that is often dreaded and warned of in software engineering circles. As Franklin says, “Experience keeps a dear school, but fools will learn in no other.” I have read the lessons that Fowler tries to spread in his book, Refactoring: Improving the Design of Existing Code, but I failed to appreciate how applicable his lessons are to my situation. My development cycle was very tight. I was developing a functional unit, testing it, refining it, and then repeating this cycle for other units. I deviated from this cycle, which served me well, by jumping into making multiple global changes at a time. After all changes were made, the suite of unit tests failed, and a sizable part of the day was lost to chasing faults.
I made the decision that it would probably be better to restart the day, since I usually leave my work each day in a stable and acceptable state to continue on the next day. This time, I took a breather and set up some scaffolding, as is suggested in a majority of the refactorings in Fowler’s book. After some scaffolding was set up, I compiled, tested, and continued. Now, I am able to make changes with less risk in a more controlled and well-tested manner. The scaffold allows the code to be functional, while it is being refactored, even if refactoring spans more than a day. Having unit tests available seems to be the primary factor in making this possible, because verifying consistency in a module’s behavior and detecting unintended effects without such tests is likely to be difficult.
The order was submitted on September 10, 2007. It was previously delayed until sometime between October and November. Now, the delivery date is estimated at January 9 to January 11 of the following year! Amazon is amazing. I’m afraid that if we stick around again, they’ll just move the delivery date another quarter.
I simply want the book at the agreed price in the agreed condition that was determined at purchase. So, it looks like I’ll have to accept the delay.
When most hope was lost, a firmware upgrade brought results. After resolving a character set problem with cdrecord through a downgrade, I received a “0x30 Qual 0x05 (cannot write medium – incompatible format) Fru 0x0” error and thought the problem was with the DVDs that I had just purchased. The DVD burner identified itself as “DVD_RW ND-3520A ‘ Revision : ‘1.04’.” After performing the firmware update, the Revision number became 3.07. I was successful in performing a bus scan with cdrecord and doing a dummy write.
The firmware update application required a Microsoft Windows environment. Because the only machine in my possession that operates on a Microsoft Windows environment is a laptop, there was a bit of effort needed in applying the firmware update. I needed to install Microsoft Windows along with assorted drivers on a desktop machine to run NEC’s update application. A task that could have taken about ten minutes required about six hours, because vendors continue to assume that everyone uses Microsoft Windows. It would have been a lot easier, if NEC provided a self-contained bootable image that delivered the firmware update.
For what it was worth, I am glad that the following was ultimately successful:
~$ cdrecord -R -v -sao myiso.iso
A Seagate drive and Maxtor drive failed over the week. Now that Maxtor is Seagate, I’ll be sending both drives to the same company for replacement. I can only hope that they return drives that are remanufactured or better, before the Seagate drive that is currently knocking away in my desktop fails.
Kathy Sierra’s Don’t Make the Demo Look Done provides excellent advice for conveying the state of a project while presenting the project’s functionality. It also discusses advantages such as improved user feedback. With a very rough presentation, users will be comfortable providing inputs on significant system features rather than the particular fonts used in the mockup, for example. The article also mentions other problems that are created by misrepresenting a project’s state.
I have read several software engineering books, and they all discuss requirements acquisition through the use of mockups. Books warn of client confusion when project estimates that are given by software engineers surpasses their expectations. After all, the system seems practically complete after they have seen a polished mockup. Making sure that a client understands that the mockup does not represent the project’s level completion is one way that some books suggest to avoid surprises. Sierra suggests that mockups can be used to give clients a better grasp of the state of the system being developed.
