Jeff Djevdet

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”

Products, Not Applications

The other day I wrote something about DevOps:

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.

So, while puttering around on those interconnected networking pipes called the Internet, I came across the TechBeacon fifth annual State of DevOps report.  And it stated that:

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

Continue reading “Products, Not Applications”

DevOps: Standardizing The Journey

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:

  • Servers created
  • Active Directory groups created
  • Accounts created
  • Databases 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.

Stop Overthinking

Psychology Today had an article last year entitled “Why Does Overthinking Sabotage the Creative Process” where they stated:

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.

Continue reading “Stop Overthinking”

Concentration Is Not Overrated,_crowded_office_space_(2899334278).jpg
Wikimedia Commons

Being able to concentrate on a problem is a wonderful thing.  The idea that you can have some peace and quiet and really get your head around a problem is, to me, a blessing.

So why do many organizations screw this up? Joel Splosky is the CEO of Stack Overflow.  For those unaware of Stack Overflow, it is a very popular site for developers to go to get answers to questions.  It is the site to go to.  If they don’t have the answer than you have a very unique problem or you need to use different keywords when searching.  Joel doen’t like the concept of the open office.  His anecdotal evidence indicates that developers don’t like it either. Continue reading “Concentration Is Not Overrated”