TA’s Sugar Bowl Cinnamon Buns

This is a Cinnamon Bun recipe created by Travis Anderson, as a adapted from the Sugar Bowl here in Edmonton. The Sugar Bowl is known for their great cinnamon buns, and recently “released” their secret recipe. That being said, after following the instructions exactly, I couldn’t help but notice my results were nothing like there own. Anyway, I think Travis has cracked the code and come up with his own tweaks the work quite well.

Modifications to the Recipe:
Use 1440 Grams of flour
3 cups of Milk at room temperature instead of Water
3/4 TBS of salt
3 eggs at room temperature
1 1/2 TBS of instant yeast
1/2 melted butter

Steps:
Mix up the wet ingredients add 1 tbs white sugar and the yeast
leave for like 5 mins
Combine flour and salt in another bowl
Add the wet stuff and mix until integrated.
Add a bit of water if necessary, knead until a fairly firm dough forms. You may need to knead, let it relax, knead again. Let bulk fermentation go for like a half hour or so.
Mix 3/4 cup cinnamon with 1 1/4 cup brown sugar.
Melt about 1/4 cup of butter and spread it in the bottom of the two pans you will use. Sprinkle the crap out of them with the cin/sugar mix.
Divide the dough and roll out like baguettes into long ropes. Look it up on you tube if you need advice on baguette rolling.
Take room temperature butter and smear on the ropes before rolling in more cinnamon mix. Tie into knots and place in the pan. Let rise for an hour and then retard the dough overnight in the fridge.
Take out in the morning and while the oven pre-heats, melt butter and brush the tops of the buns. Sprinkle more cinimix on top and bake.

10881580_10155050985755389_7781509576794708075_n

The Fine Line Between Scope Creep and Proactivity In Software Development

Lately I’ve spent a lot of time internally debating one of my personal software design philosophies. Namely, to what extent, or if at all, should one go above and beyond the idea of MVP(Minimum Viable Product) when developing software?

That is to say, is doing the bare minimum to achieve the desired functionality perhaps even with disregard to the systems around you the best practice? Does the old saying, “If it ain’t broke, don’t fix it?” still hold water? Or is it worth taking that extra 10% of time to slightly re-architect the systems around you with consideration to that extra piece of functionality you’ve tacked on so that it doesn’t explode from the seams the next time you need to add “just one more piece of functionality”?

I’ll be the first to admit that as a fairly inexperienced developer, I have been known to be enthusiastically heavy handed when developing new systems or features. Where a chisel would have been the best tool for the job, more than once my tendency has been to immediately equip the refactor bazooka and fire at will. While I’ve built some pretty cool things as a result and made some pretty impactful changes, the void of code being released in the middle is disheartening. Not to mention the, “Hold your breath… here we deploy.” moments when the code is actually ready to ship.

As part of cleaning up my act and pursuing better development habits I’ve been making a conscious effort to refrain from these sorts of tasks and in many cases push myself in the opposite direction. Which explains how I arrived at this quandary in the first place.

In many cases it pains me when I know with just a bit of extra work, the “just get things done” changes could be made into elegant changes which improve readability, testability, and extensibility in the future. But is that really necessary or is it the case that doing this like this is simply over-architecting. Maybe it is true that if it isn’t breaking the current system or that in which you are trying to implement, then it should be left alone until it does.

My gut tells me that this isn’t the case. If you’ve been working with a code base for an extended period of time and you understand your current feature set and the foreseeable roadmap, then isn’t the extra 10% overhead now worth saving you the headache later on when the system you’ve been hacking things onto actually does explode?

I understand the arguments against this idea, or, at least trying to silo your changes to one scope of work at any given time. But from my experience, as working in a startup, “I’ll make that change in a later pull request”, really means, “It’s not going to get done.” So, with all that being said I ask, where is the line in the sand that one must draw when making these decisions?

Anyway, I’d love to hear from you, what your experiences are on this, and what I’m missing. I wrote this in about 30 minutes, probably in procrastination in studying for my American Politics Final tomorrow so hopefully it’s not too raw.