Regretting a lazy design

Last night of the iter­a­tion, we are try­ing to cut a good build. This morn­ing’s scrum fea­tured a flus­tered QA engi­neer who was hav­ing trou­ble com­plet­ing her tests due to “cor­rupt­ed data”. Developers look at each oth­er and think, “rebuild the VM”, but it real­ly turned out to be faulty (and incon­sis­tent) assump­tions, on all of our parts.

The root cause of all our prob­lems tonight, though, dates back to the removal of a data­base con­straint that sup­port­ed an assump­tion that was not removed, about three iter­a­tions ago. (A ques­tion­able design deci­sion, IMHO.) This iter­a­tion, we tried to add a new con­straint that enforced our (now refined) assump­tion in a dif­fer­ent way. We failed. The assump­tion had been bro­ken in sev­er­al places, includ­ing our test data. Now, as we are try­ing to go gold, we have found that we need to revert the con­straints and deal with the messy data, just so that our test suite will con­tin­ue to work.

Now, in the­o­ry, in the field, nobody should be break­ing things. But we are still allow­ing them to, so some­body will, and it will look bad for us. We are stuck between a rock and a hard place now. Thirty min­utes spent com­ing up with a bet­ter design three iter­a­tions ago would have had us at home with our wives and a beer three or four hours ago.

Tags: Late Nights At Work