Best Practices

In this world, there are those with common sense, and there are managers. In the world of high finance, there are only those with power and those without it. Those who have power make decisions - regardless of their familiarity with the relevant subject matter, or their ability to prioritize things involved in the decision. Those who don't have power (aka: us) live with the aftermath.

James T. joined a major financial company. Because they have over $1B in revenue a year, he was under the impression that these folks knew what they were doing. They paid very lucrative salaries. They all seemed intelligent. They talked a good game about best practices and doing things right. They hit all the right buzzwords during the interview.

What James didn't realize is that they were power brokers who used words without understanding what they actually meant.

We do Modular Development. Translation, each person works in a vacuum to build their own little modular piece of the system. There is no need to talk of interfaces because management doesn't know there's a need for different pieces of the application to communicate with each other. It just has to work. (Magic happens here).

We design our programs so that they lend themselves to code reuse. Translation, find some piece of code that is close to what you need, make whatever changes are necessary and cut-n-paste it into the new program.

We discuss different approaches and the Best Idea Wins. Translation, the boss has the best idea because he has the most experience, so we do it his way.

We build Frameworks. Translation, a framework is just an application to perform a certain task. It does not need to be generic because it only needs to do one or two things, so we just hard-wire everything.

OK, so programming application-specific code might not be the antithesis of framework development, but it's close enough. When trying explain the value and difference of framework code to application code his boss literally asked Why would anyone ever need that?

As it turned out, most of their "developers" were really engineers and traders. Like most businesses they're ingrained into their current paradigms. Like some engineers, they're very resistant to doing things differently.

So James is building his little single-purpose reusable module and has some questions about the specifics of what it's supposed to do. In response, his management advises him that the details are unknown at that point, but that he should forge ahead, and they'll figure out what it's supposed to do after he delivers it and they see if it's useful to the end users in production!

Forget measure twice, cut once; these folks threw away the tape measure and grabbed a power saw, leaving mountains of scrap lumber all over the place. Then they wonder why it takes so long to get anything useful delivered.

[Advertisement] Incrementally adopt DevOps best practices with BuildMaster, ProGet and Otter, creating a robust, secure, scalable, and reliable DevOps toolchain.