Code & Run / Speed Kills

For a long time, I have harped that code & run shops are not going deliver any business or employee sustainable results.  It’s pretty much common sense to me, but a lot of businesses do not give a damn or get it.

It obviously causes all sorts of BIG problems for businesses and the people they employ:

1) Unnecessary pressure.  Working till all hours to produce hacks, not code.  Affects all parties involved due to the expectation to code & run against ridiculous and lack of well thought out process or deadlines (developer, managers, and their families are affected as an indirect result of lack of any process, priorities, or iterations)

2) Employees leave because of the chaos which includes not only uncontrolled changes, but also constantly staying up to fixing hacky code in the system or refactoring code just so they can build on it again

3) Business constantly refactoring the shit due to “speed” rather than “quality and normal pace with defined iterations & prioritized lists of projects”

4) Businesses result in ultimately purchasing third party apps (which would not have been necessary) because the lightening speed and lack of testing produced a pile of shiza.  So what do they do?  they resort to buying 3rd party pieces of shiza that 5 years down the road have to be replaced AGAIN.  Rather than taking an interative approach (agile) and add realistic deadlines to iterations with padding (which makes the business happy because those iterations are being met), they code in a chaotic culture and produce scope creep and more cost to the business (bugs).

There’s really not much to go on about this.  It’s simple, common sense development.  Why it’s so hard for businesses to calm down and realize this, I don’t know but the excuse that “we have to have it fast to make money” only goes so far until one day BANG…guess what, we just lost a ton of money due to this mindset and lack of process (continuous build environment with source control, design patterns, etc.), deadlines that cannot be met with a tolerable pace, deadlines that change frequently due to chaos (no prioritization), and lack of documented and well followed team development standards within.  So much for the pride of “speed”. 

I personally like to pride myself on working code, a working & unit testable application that is usable and extensible (by me or other developers down the road) for my users now & in the future.  That’s what professionalism is in development and what keeps your development team motivated...not burned out.  And that’s what will make the business money in the long run and consistently hit the bottom line.  While there is definitely a need to get things done in a timely manor…that does not mean foolishness in those timelines.

I will extend on this with how (based on my experiences) you can create an effective development environment and realistic deadlines in a future post.

Here’s a great article; I can’t say it better myself: Speed Kills (by Uncle Bob)