Why you shouldn't introduce "stuff" into your technology stack

Creativity is why I code.  Wiring "things" together is creative.  When the "things" become an end-to-end system, I know that I have accomplished something which is robust, and does "what it says on the tin". Why would I want to risk that?  I don't, and here's why.

Why is technology different to building a house?

Well, the house relies on builders, architects, and the odd cup of tea to get the job done. Your average man-in-the-street does not claim to be a bricklayer, or able to lay foundations.

Compare software development, coding, programming….. more people claim to be able to do this:

  • The person, who says “I used to be a programmer”.

  • Casual programmer who claims to know a lot.

  • The guy on a train who comments on your code.

An opinion is welcome, but make sure it doesn’t compromise your technology stack.

In other words, don’t allow none-standard, inconsistent, badly-documented software to be introduced.  If your stack is Python, Django, and Tornado, don’t introduce a Perl CGI, which someone thought could “do the job quicker”.

Why can’t someone introduce a bit of Perl….?

If we go back to building our house, would you ask someone who had only done a days brick-laying to build the walls of your house?

I wouldn’t, because of lack of skills.

But, the real reason is service delivery, which means making sure that the software and systems are supported, in a measurable way.

Who is going to look after it, and how is it going to be looked after?

The Perl is not easy to support, as you don’t have the skills.

Why don’t you have the skills.   Because your technology stack is Python, Django, and Tornado.

Perl is another programming language, with different infrastructure and configuration concerns.

Author | Miles Davenport

Career programmer, who designs, assembles, fixes, and supports customers, software and systems.