Regretting a lazy design

Last night of the iter­a­tion, we are try­ing to cut a good build. This morning’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.

YAML To The Rescue?

Here at work, we have been run­ning into a lot of issues syn­chro­niz­ing the default con­fig­u­ra­tions pro­vid­ed by the devel­op­ers with those that have been pro­vid­ed by the team respon­si­ble for pack­ag­ing releas­es. The sys­tem as it is right now is, how shall we say, clunky, at best, requir­ing the devel­op­ers to go back and recon­fig­ure new fea­tures mul­ti­ple times through­out an iter­a­tion, often every evening before the night­ly build. This sim­ply will not stand.

Continue read­ingYAML To The Rescue?”