Trends – Customize Code

Book Review – Atomic Habits

Posted on January 27, 2020 | by ccadmin | Leave a Comment

I look at every day as an opportunity to improve myself not just on new years. If you’re into improving systems (Such as using DevOps) then why not improve the most important system you have…Yourself.

James Clear has written in my opinion a clear and practical way of changing your habits by working on a system of habits in his book Atomic Habits. Instead of having a resolutions such as “I will lose 500 pounds by the end of the year” or “I will make $1,000,000 a year” which are for the most part impossible goals since you don’t have the systems of habits needed to not only reach the goal but to support it in the long run.

Without the system, more than likely even if you reach your goal let’s say losing 50 pounds… without the systems of habits, months after you reached your goal you would have not only regained the 50 pounds you lost, you have gained another 25 pounds on top of that. The same thing that happens with the Lotto winners who won a million dollars, they end up spending it all and being worse off than they were in the beginning.

What are the Systems of Habits? Every system is made of smaller individual components or atomic habits. Instead of doing many individual tasks that require lots of conscious effort, why not build a collection of complementary habits. For instance, suppose you want to write a book, you start with a daily habit of writing 50 words a day in the morning. Writing not when you feel inspired but out of habit.

James Clear gives several examples of building habits that help you obtain long term goals. Marginal incremental gains will result in tremendous long term gains. Each habit has a long term cumulative effect on reaching your goals.

An example he gives is the British cycling team. In over a hundred year s they, only one gold medal in the Olympics in cycling and they never won The Tour de France championship. Enter David Brailsford, a specialist in marginal gains. He started changing little things such as the clothing that the riders would wear for wind resistance. Bicycle seats were more comfortable for the riders. Matresses and pillows were more comfortable to give the cyclist a better night’s sleep. They also changed the type of gels they used for muscle recovery. Painted the inside of the vans white so they can see if there was dust in the vans. Hundreds of small improvements. In less than five years, the British cycling team started winning gold medals. They dominated the cycling event in the Olympics in China. Three of their riders went on to win the coveted Tour de France multiple times (2012, 2013, 215,2016,2017,2018).

The idea is to work on small consistent habits that you learn to do without thinking and effort that complement other habits that help you achieve your long term goals. Those habits don’t stop after you reach your goal, they continue and allow you to achieve the next goals you have. Pushing you forward without much effort. Just getting started is the hard part.

I have already applied these principles to developing a system of habits of my own.

Here are a few examples of things I’ve done to be a better writer:

1 – Review daily a technical stack such as a framework, language, operating system, etc.

2 – Write at least 50 words a day in any form, such as an article, discovery journal, etc.

3 – Exercise every day at least one pushup.

Each one of these habits complements each other towards the goal of being a better writer. Reviewing the nuances of a framework or language helps me to keep my skills sharp on languages or frameworks I don’t use as often. Writing regularly not when I’m inspired or under a deadline keeps me consistent and disciplined in my writing. Exercise helps me keep fit and helps me manage my energy as I write.

I make it convenient to track my habit with a Goal Tracker app on my Android phone. I use an Anki App for my Android device to review things like IOS and Javascript.

What I notice I started to do after a certain point, that the daily checklist activities became automatic. They became habits I didn’t have to think of tracking at some point. All of these habits aid in reaching my long term goals.

I highly recommend this book not only to learn something about yourself but learn HOW to think strategically about developing habits that help you reach your long term goals.

The Elephant in the room – 3 key points of DevOps – Strategy, Tactics and Implemention

Posted on January 14, 2019 | by ccadmin | Leave a Comment

Elephant in the room?

When people talk about DevOps, most people don’t know what their talking about or usually they only know part of what is DevOps. The blind men describing an elephant is what comes to mind.

One blind man says he feels it’s like a rope. The second blind man said it’s like a thick branch of a tree. The third blind man said it’s a huge wall.

DevOps is the elephant in the room.

We tend to only “see” one part of the elephant and we view it from our own role or perspective.

For many people, the answer of what is DevOps tends to falls between these kinds of viewpoints:

To systems administrators, it’s about use of Automation techniques to manage many machines and deploy code (i.e.Ansible, Kubernetics).
To a developer, it is a consistent code development environment and automated integration system (i.e. Docker, Git).
To a project manager and stakeholders, it is an Agile development methodology for software and product development.

These answers are both right and wrong at the same time. This is where the understanding of Strategy and Tactics come into play. With this, you can recognize and understand the “elephant in the room” and how to use these tactics and strategies.

The Difference between Strategy and Tactics

The culture and management practices of DevOps can be looked at as the Strategy. The implementation DevOps in the form of tools and processes used are the Tactics. One is at a global level, the other is the “hands on” task(s). Strategies don’t change often. Tactics do change depending on the situation. It’s an important to understand these perspectives to understand what “DevOps” really is.

What is Strategy from the DevOps point of view?

Strategy is the plan to archive a long term goal. DevOps may employ many different strategies. Here are a few examples:

Continuous integration is a strategy.
Break down silos is a strategy.
Lean software development is a strategy.
Treating servers as cattle not pets is a strategy.
Sizing teams no more than you can feed with two pizzas is a strategy.

These strategies are NOT always going to be appropriate for your shop for a variety of reasons and may need to be modified or other alternative strategies may need to be used. SCRUM vs Lean? Up to you and your team.

What is Tactics from the DevOps point of view?

Tactics is the actual methodology of implementation of a strategy. Depending on your own needs and circumstances, the tactics you chose depend on the strategy your seeking to fulfill. Here are some examples of of tactics:

Using a Git shared repository is a tactic for Continuous Integration .
Using Kanban software and workflow is a tactic for Lean software development.
Using Ansible to setup standardized servers is the tactic for the “cattle not pets” strategy.
Having small team of five people consisting of people from Operations, Development and Quality Assurance is the tactic for the two pizza team and break down silos strategy.

Tactics may change for different systems you manage. For instance an MDM (Mobile Device Manager) platform would be the appropriate choice for managing Smartphones NOT Ansible or Chef and in this sort of environment, Docker may not be appropriate for development of the front end app.

Implementation is the key

Even after understating the Strategies of DevOps and developing the Tactics to implement DevOps, if people are not DOING the tasks to implement the tactics, just doing what they always done, they don’t have a DevOps shop. People need to participate. The place to begin is with collaboration and creating an environment where there is trust and the people involved are actually carrying out the tactics as day to day activities. To get collaboration, people need to have ownership in the project and get recognition for their part. Create an environment where people are willing to take risks and are not afraid of failure. To do this, it’s important that failure is valued as part of the learning process instead of blaming people or finger pointing. In fact back in the 70’s at IBM, Tom Watson Jr. recounts calling to his office a young executive made a $10 million dollar mistake. Expecting to be fired, the executive presented his letter of resignation. Tom Watson just shook his head:“You are certainly not leaving after we just gave you a $10 million education.” Learning from failure is part of IBM s culture, it should be part of every successful company s culture.

There is NO right way to do this

You can read books like The Phoenix Project or The Goal (Which The Phoenix Project is based on) and apply the Theory of constraints, or read any number of books written about DevOps. However, the original talk they done on 2009 10+ Deploys Per Day , Allspaw and Hammond didn’t do something all that new as these concepts were done by others. Lean manufacturing is where Kanban and Lean software development came from. Site Reliability Engineering , which is in principle DevOps, was developed at Google around 2003, well before the Velocity 9 conference. At Netflix, they weren’t thinking about DevOps when they developed their “DevOps” shop.
I am of the opinion that you have to examine BOTH the STRATEGIES AND TACTICS of what worked at various organizations and what didn’t and focus on collaboration. Building a collaborative environment that encourages ownership of a project, gives recognition and encourages people to take risks and not be afraid of failure is the key first step to creating a DevOps shop. Doing this will make adopting the “Elephant in the room” less intimidating and will put DevOps in your grasp.

Feel free to give me your comments and suggestions.

Until then, have a great day.

DevOps vs Systems Administration – Why should I care?

Posted on November 30, 2018 | by ccadmin | Leave a Comment

Originally, I was going to write about Ansible and how to run it in a Windows environment using Vagrant, but as I started to write the article, I found that I had to describe how these tools were used and developed around the culture and philosophy of DevOps. Then, it occurred to me, I needed to describe what is DevOps. According to Wikipedia, DevOps is a software development methodology that combines software development (Dev) with information technology operations (Ops). Of course, I’ll use DevOps definition in a broader sense and more oriented towards operations.

Why should I care? Isn’t systems administration and DevOps the same?
Not exactly. Being brought up on old school Unix Systems Administration, I remember when machines consisted of dedicated hardware(CPU, Memory, Framebuffer, hard drive, etc.) software and network switches and routers. I would spend hours configuring individual machines using scripts or installing software (or compiling it) one machine at a time. I would be working with a team of people it seems firefighting. Keeping up with the demands of the users and their needs for additional resources…well was a pain. Then we turned the corner with virtualization where your machine is just a disk image sharing space on high powered hardware, more efficient, easier to use programming languages such as python & ruby (though this can be debated, but these languages are easier than programming c) and working towards automation. Mass on demand Virtualization is now called “cloud computing” or what I call Commoditized Virtualization. You can get VMs on demand and pay for what you need even by the hour. Out of these merging of technologies and software development methodologies (such as Agile) is where DevOps finds its origins.

Contrasting Systems Administration with DevOps.

Systems Administration tends to focus on being a tech…that is a power user who loads and configures software and plugs in hardware into the system. DevOps on the other hand focus on programming and automation of the system and network infrastructure. The mantra is “Infrastructure is Code” where you write and run code to make running the systems and network infrastructure more predictable and controlled.

System Administration tends to be reactive. That is you plug in the hardware/software and find out if it works and fix it as you go. DevOps is proactive in its approach. Use automation in a consistent and predictable way by using tools to test in a development environment before releasing it into a production environment.

System Administration tends to follow a “waterfall” approach to planning, getting requirements and deployment. You tend to make big expenditures of capital, time and resources up front. You fix it as the complaints come in. DevOps approach is more “agile” with many smaller changes to the system with plenty of user feedback BEFORE it’s all rolled out as well as DURING and AFTER the rollout.

While your company or organization may not be a software development house, i.e. you may be a web design company or your supporting your own companies internal network, you WILL benefit from adopting a DevOps approach as this can be applied to:

1 – Rolling out new software to your internal desktop users and keeping them current.
2 – Keeping your customers websites updated using automation tools.
3 – Being able to show management (and other stakeholders) what is accomplished and what is needed. You keep them in the loop.

While this is not ment to be an exhaustive treatise on DevOps, this should open your eyes to what is useful and what is possible.

In the meantime, have a good day.

Roy

Software is perishable – Identify your HIDDEN requirements.

Posted on November 19, 2018 | by ccadmin | Leave a Comment

Software is perishable

In a world where fresh food goes stale then rots, pets are born, grow old and then die, software is perishable. What do I mean by that?

Requirements change

Isn’t software something that once it’s written just does it’s task and doesn’t change? Yes, that is true, but the REQUIREMENTS needed to keep software useful will change over time. Often the changes can be swift and rapid. This can get you and your business into trouble if you don’t keep your eye on it.

A way to look at software is what reason did you get the software in the first place. It filled a need, a requirement.

For instance, I get an accounting package…lets say KwikyBooks. I get the package for my accounting needs. Well, what are my requirements?

1 – Generate invoices of my customers.
2 – Take payments and track this information.
3 – Generate various reports.

Hidden REQUIREMENTS

However, there are HIDDEN requirements that may not be obvious until you start using your software:

1 – What kind of hardware does this software run on. If you can’t obtain or afford the hardware, the software will be useless.

2 – Is the software secure? If you can’t keep your confidential business data safe, you will lose customers because they can’t trust you to keep the information safe. It’s just a matter of time before someone or something hacks your system.

3 – Is the software keeping up with industry standards and practices? Is it compliant with Federal, State and Local laws? E-commerce businesses, depending on it’s size, for example may have to track sales tax in EVERY STATE it sells to. Every year the Federal and Local government adds new laws and regulations that affect accounting and Tax laws. Having software that is non-compliant with industry standards and laws can cost you money and even your business.

In the same way, even though your software you have purchased or have developed for your company or customers may fulfill your original requirements, the HIDDEN requirements often will change because the software doesn’t change with time.

Prepare for Hidden Requirements

With this in mined, here is what I’d suggest you do when you either purchase software or have it developed:

1 – Check on the stability of the developer or company you are getting your software from. Even if it’s AWESOME software, if the software developers who wrote it go away, you can’t get the software HIDDEN requirements fixed. If your working with an independent software developer, I would recommend you use a well known open source framework and languages. In the worst case scenario, you can find a python or java developer to take over development ant maintenance of your software than something written in let’s say a Esoteric programming language or a language that is not as common to use these days (i.e. Fortran, Pascal, Assembly, etc.)

2 – Get or obtain a service contract or maintenance agreement for the software. With this in place, you keep the software developer vested to keep your software up to date.

3 – Periodically review your requirements and discover what your HIDDEN requirements are and get them addressed.by the developers. The HIDDEN requirements are usually found in changes in these three categories:

a – Industry rules and standards – Software is codified expertise that follows the rules and standards of your industry.
b – Laws (Federal, State and Local) – Legal requirements affecting your industry or profession.
c – Technology – New technology and advancements, including updates and security fixes.

I would recommend you work with your software developer or software company to help you keep track of these areas that can affect your software requirements. Incorporate this process if you are working with Agile software developer.

In summary, please re-examine your software requirements regularly and make sure you keep you software fresh. Don’t allow your software to perish along with your business.