This week has been a killer in some ways.

I went into the office on Monday.  I walked into a project in crisis.  The features were there but the performance wasn’t.  The BAs screwed up by not pushing the users to do a full mock-cycle.  When the forecasting cycle rolled around last week, some of our users opened the app then closed it without doing any work in the tool.   Users complained that the pivot grids were too slow to update after an edit.  Performance in production was crap.

“Umm…  Why did we hear about this issue over a month ago at UAT or during last-months mock-cycle?”  Heads are starting to roll on that side of the fence.

Where am I going with this?
When I started looking at the code, it was a steaming pile of shit.  Cut-n-paste errors abound, shitty pattern selection, tight coupling, statics with parallel instance properties, shit variable names.  It was a train wreck.   And we all know, I don’t keep my opinions to myself especially when I established the framework that we use to rapidly deliver our apps.  My junior developer has had a very hard week as I forced him to sit beside me while I refactor major portions of his code.  “Why did you do this?”  “Did you not realize this is a cross-cutting concern?  Do you not see that list on the wall to remind everyone that State Management and Caching are cross cutting topics? ”  “What does this variable mean?  ‘Trans’  Is this a Trans-Am, a transsexual or a group of guys named Tran?”  “Why did you add this control to the screen?  You know we already have an existing pattern to handle that feature.  In fact, it’s already on the very same screen.  See it?  Right here in the Ribbon with all of the other buttons related to that feature.  WTF dude? ”  This went on for hours.  We’re still doing it every day.

This is a classic case of someone trying too hard to please.  Where someone goes so fast, throwing in features that they stop thinking about the bigger issues like performance, long-term maintenance, and simple read-ability.   He let the BAs tell him features were show-stoppers when they obviously aren’t.  He never pushed back when he got a shit bug report with no details, context, or steps to reproduce.  He worked a crazy amount of hours instead of telling people “No.”  And all of his efforts have ended up in a failed project.

So what was the point of this rant?

Why bother to kill yourself, write substandard code, and incur the wraith of your teammates when they have to crack it open for support.   The obvious answer is none of this effort was time well spent.  Unrealistic deadlines require someone to push back.  Not meeting a sprint curve in a 40 hr week means there is too much work.  It does NOT mean that you need to work 4 more hours every night and all weekend to stay on target.

<sigh />

This evening, while catching up on email and you tube clips, I saw a link to this article:   http://blog.salsitasoft.com/what-i-wish-i-knew-when-starting-out-as-a-software-developer-slow-the-fuck-down/

Very close to the end of the article was this line: “We need to recognize that our job isn’t about producing more code in less time, it’s about creating software that is stable, performant, maintainable and understandable (to you or someone else, a few months or years down the road).” 

That’s kinda it.  We do this work because we love solving problems.  Some times the best solution is to simply slow the fuck down.  Be introspective.  Ask questions.  Apply SOLID and DRY.  Do it right aka to the best of your ability or don’t bother.

When you’re writing Supply/Demand Forecasting applications for a Fortune 100 company, it is better to do it right than to rush and screw it up.

Slow the fuck down!