The whole family watches Canada’s Worst Driver. We regularly watch the show to see how bad people are. And some of them are really, really bad. It’s even worse when they say that they are from Edmonton. *sigh*
One of the things that they talk about is “speed kills”. I have a problem with that statement. Excessive speed does not kill, it is driving at an unsafe speed, even if that speed is below the speed limit. What is an unsafe speed? A speed at which the driver is incapable of performing certain functions to save not only their life but someone else’s life. Continue reading “Lack Of Skill”
Embed from Getty Images
OK, Don, you talk a big game, but where’s the science with regard to the space issue? How do you know that something like an open floor plan concept is actually worse for people?
Embed from Getty Images
“Space, the final frontier. These are the voyages of the starship Government. It’s ongoing mission to …”
Last week we talked about space and how the reduction in space is detrimental to personal productivity. So is more space the right answer? No.
First of all, the appropriate amount of space per person is different. Everyone has a different amount of space that they consider appropriate so not everyone will be happy. That’s just the way it is. Some roles need more space than other roles. Not your level (System Analyst, Manager, etc.) but role. Continue reading “Creative Space”
OK, I’ve complained about this before but you know what? Time to revisit from a different perspective. Office space. Space is at a premium and we cram more and more people into smaller and smaller spaces. Is this the right thing to do? Well, let’s talk some facts. Continue reading “The Optics Of Office Space”
I saw an article the other day and the title was fantastic: How terrible code gets written by perfectly sane people. The author was porting code from Python to Node and was looking forward to the challenge. What he didn’t expect was the code, written by a group of senior developers with good skills, sucked. (OK, he didn’t use the word sucked, that’s my interpretation when he said the code was “the product of a room full of babbling monkeys copying code randomly from Google.” See? It sucked.) Continue reading “Process Versus People”
Continuous improvement versus innovation. What is the key differentiator between the two?
Let’s talk about batteries. There are a lot of things in our lives that use batteries. For the longest time the world used zinc-carbon batteries and then came alkaline batteries and the Duracell bunny and then Lithium-IronSulfide batteries. Yeah, I never heard of those last batteries either. Each generation added more capacity. Alkaline had 50% more capacity than zinc-carbon and Litthium-IronSulfide had 100% more capacity than zinc-carbon. Incremental improvements. Continue reading “Improvement Versus Innovation”
What motivates you? Let’s get the standard things out of the way and assume that your house is not going to be repossessed, you have money for electricity/water/cable and that you have adequate food. Once your physical needs are satisfied, what motivates you, what satisfies you? Daniel Pink, the author of Drive: The Suprising Truth About What Motivates Us believes he has the answer: autonomy, mastery and purpose. Continue reading “Motivation”
We shouldn’t be lulled into the idea that DevOps is restricted to just the technology pieces of development and operations, it is pervasive in nature and covers the entire SDLC, including the management of projects.
This year’s report shows how improving the entire product lifecycle – from initial product planning to quality and security assurance, to customer feedback – speeds up delivery while improving quality, security and business outcomes
Sometimes I come across an article which is narrowly focused, but has applicability throughout the universe. OK, maybe not that all-encompassing, but almost. For instance, just the other day I was reading an article entitled “DevOps and the DBA“. Kind of a narrow focus, but a couple of sentences really stood out for me.
Operations staff take the view that speed invites chaos, resulting in instability, downtime, and a lack of sleep. The reality is that chaos, instability and downtime are not the result of speed, but the result of variance.
The goal is to enforce consistency, and to manage our resources so that the software is deployed in the same way that a car factory builds an automobile.
Wow. That kind of sums up the DevOps movement in general. In order to automate something, you need to standardize something – the tool, the approach, the steps – and the more you standardize the more you can automate and the fast you can automate. I was attending a Forrester conference call a couple of weeks ago and the presenter was talking about how Amazon has seven different templates to move things into production. Just seven. Now, by any stretch of the imagination Amazon is a big company. If they can do it, why can’t we? Why is it that we have to customize all of these deployments for our deployment tool instead of using just a few templates?
But the idea of standardization is not new, nor is it restricted to just deploying applications into production. The entire software development lifecycle is full of standards, but sometimes not the correct standard.
Back in the good old days, we used Excel for project management. (Yes, some of you still use Excel, but there are better tools out there.) It was a standard template for how we built applications. The template remained the same and we just added line items for the exact pieces that we were building. If we were building two web pages, one low complexity, and one medium complexity we added two lines into the Design section, two lines in the Build section and we were done. We told the spreadsheet what complexity the web pages were and it used a lookup table to pull back the numbers for the spreadsheet. Testing? It was a set percentage of the Design and Build estimate. It was standardized. It was simple. It was accurate. We used previously executed projects to populate the lookup table and we had years worth of information that we could mine. By standardizing on a template we were able to make effective use of the data that we accumulated doing the last project and the one before that and the one before that and …
Now, imagine a world where you could go to a single site and tell it that you are starting a new project. You give it a name, an acronym, the people on the project and by pushing a button you get:
Active Directory groups created
Project Plan created
Automated workflows created
This is possible through standardization. This is the dream of DevOps, this is the target that we should be striving for. The fewer decisions that need to be made on mundane things (Where do I go to get servers created? What databases do I need? What should I call them? What security needs to be set up? What do I need to put in my Project Plan? When should I get the automation workflows created?) the more effort can be spent on building a system that exceeds everyone’s expectations.
We shouldn’t be lulled into the idea that DevOps is restricted to just the technology pieces of development and operations, it is pervasive in nature and covers the entire SDLC, including the management of projects. DevOps isn’t a thing, it is a culture shift that is both invasive and inclusive. It will change how you plan and develop applications and it requires that information be fed back into the process in order to continually improve and to ensure that the process is advantageous to the organization.
DevOps, from planning to executing to implementing, is about making things easier. It’s a long road to get there, but the more we look at the entire SDLC the more advantages we can discover on the DevOps journey.
Many scientists believe that the creative process springs as much from the subconscious as it does from a conscious thought process. Most often, creative solutions are not wrestled from your mind through sheer force of will.