Keeping Code Clean
Wikimedia Commons

More good quotes:

A culture where problems are fixed as they appear is one of the most fundamental traits of successful projects. – Abraham Marin-Perez

How many times do we come across a pile of … wrongness . and don’t fix it?  (While this can refer to almost anything in your life I am going to restrict my discussion to projects and IT.  Feel free to extrapolate to encompass your whole life.)  Have you ever walked into a kitchen, wanting to bake something but found that nothing was in its spot and the entire kitchen was a mess?  Yeah, neither have I but that’s because I’ve never really had a desire to bake.  Except for these wonderful chocolate chip cookies that we got from a recipe on the Internet.  Anyway, back to the story. Continue reading “Keeping Code Clean”

The Shifting Skill Curve
Wikimedia Commons

I came across a quote the other day that completely explains IT:

There will always be people who are ahead of the curve, and people who are behind the curve. But knowledge moves the curve. – Bill James

You can be competent in a technology, but when that technology changes, when it evolves, when the knowledge about that technology changes, you may end up behind the curve.  For instance, if you grabbed on to Visual Basic when it first came out (like me) you may have become competent or even proficient in that technology but unless you changed, unless you grew, you fell behind the curve. Continue reading “The Shifting Skill Curve”

Your Clients Want Pokemon Go
ColiNOOB (via Pixabay)

Imagine this conversation two years ago, no, two months ago, no, just last week:

So, I rushed home and told my wife that there was a lure at the church and we need to go before the time ran out.  She grabbed her phone and we went down the street to the Stop at the church and saw a lot of people in the parking lot.  This was going to be great.  So we stayed for a while, dropping incense, grabbing some loot from the Stop, and capturing all the critters that spawned.  And you know, it was right next to a Gym!  We saw the gym go from Blue to Red to Yellow and back to Blue with a beefed up Vaporeon at the top.  It was awesome.  Anyway, someone else dropped another lure but we needed to head home ’cause, well, dinner was ready, so we reluctantly said goodbye to the crowd and went home.

Darn, Pokemon Go is fun.

Continue reading “Your Clients Want Pokemon Go”

One Government – Data-Wise

My brother has worked for a large number of insurance companies either on the accounting or in sales.  He’s been at the bottom of the totem pole and VP in charge of something or other.  (I think it was commercial insurance for western Canada.)  One of the things that he wanted to do more often, but which he was discouraged from doing, was sending cases to their private investigator and then to court.  It always came down to money:  how much was it going to cost to hire a private investigator, how much were the lawyers going to charge to fight it in court, how much would it cost for internal staff to evaluate the information and determine if criminal charges could/should be brought and a litany of other factors. Continue reading “One Government – Data-Wise”

Objectivity in IT
ccipeggy (Pixabay)

Within IT we constantly talk about how people are supposed to bring us their problems and we will work with them to come up with solutions.  We don’t want people to come up with their own solutions and ask us to implement them, we want to know the problem, understand the problem, embrace the problem, make the problem our own and then solve it for them.

This has a lot of advantages.  Because we have an understanding of their business and other related businesses we can look at areas of re-use, we can look at areas where we can literally copy/paste code and get a leg up on development, we can look at the problem from a holistic perspective and perhaps come up with a different solution that meets the needs but gives them additional capability.

So why is it that we don’t do this ourselves.  Too often applications internal to IT are not brought to IT for a solution but are brought to IT with a solution in hand.  Instead of trusting the cumulative experience within IT we come up with a solution, regardless of whether or not it is the proper solution, and then rapidly build something with that solution in mind.  We don’t review it as we would a solution brought to us by a business client and we don’t ask for the problem so that we can determine the best way to resolve the issue, we jump to a solution that may or may not be appropriate.

We also need to understand where our biases lie and work to mitigate those biases when trying to resolve problems or evaluate solutions.  For instance, I have a bias against COTS packages that you can modify.  I’m thinking primarily of things like PeopleSoft and SAP and Oracle Financials, but it applies to other COTS packages as well.  I have experienced too often, actually, the IT industry, in general, has experienced this, that people buy a COTS package and then highly customize it.  Then another release comes out and that needs to be highly customized.  Ad nauseum in perpetuity.

When I first started in this business over thirty years ago I worked for a company that had modified their payroll system so much that it took them almost a year to make updates.   The company that produced the payroll system came out with bug fixes and updates every six months.  We were always behind.  PeopleSoft?  The same way.  Months and months of changes, sometimes extensive changes before anything could go in.  And when it did get into production?  Bug fixes that were fixed by the next release that came out six months prior but we were too busy working on the previous release.

I understand that bias.  I know about it.  I try to make sure that it doesn’t impact my assessment as to whether or not a solution is appropriate.  Sometimes COTS products are such a good fit that it would be silly to try something else.  Sometimes it is close, but the remaining twenty percent?  That’s really the meat of the application so while it looks good on paper, it is not worth it pursuing.

A number of years ago there was a bias that SharePoint was the development platform of the future.  Everything would go into SharePoint.  I mean, why not?  A data connector here, a simple form there and *bam* a new app in hours.  As we have seen, not everything that can go into SharePoint should go into SharePoint, but for SharePoint adherents SharePoint was nirvana.

Every so often a technology comes along that people become enamored with and think “Wow, this will solve all of my problems.”  It won’t, it will just cause more problems down the road.  You need to pick the right tool, the right solution, for the appropriate problem.

You don’t ask a CMS adherent if the solution to your problem is a CMS, because the answer is “Of course!”.  You don’t ask a SharePoint aficionado if the solution to your problem is a SharePoint site because the answer is “Of course!”.  You don’t ask a PeopleSoft person if your problem can be fixed by PeopleSoft because the answer is “Of course!”.  You don’t ask a CRM fan if the solution you’re looking for is built with CRM because the answer is “Of course!”.

Our job is to be objective.  Our job is to look at all solutions dispassionately and come up with the best solution given the parameters that we need to consider.  So why is it that for solutions that IT builds for itself we rarely do that?

Feature Flags

Darn, this thing called “software development” keeps changing, keeps advancing, and you have to keep reading in order to keep pace.  The topic today?  Feature flags/toggles.

One of the issues that we have is multiple teams (application development. application maintenance and more) accessing the same code base and making changes at the same time.  The problem is trying to merge changes from Project A into what Project B is doing while at the same time making sure that the team handling the main trunk, maintenance, isn’t left out in the cold.  This can be handled through branching and merging back into the source trunk, but it can be difficult if you have multiple projects going at the same or even if you have just two projects, but their deployment schedules aren’t firm.

The other way to do things is to use something called a feature flag.  In this model everyone works in the same codebased, checks in code all the time, but their feature, what they are working on, is not visible until their feature flag is turned on.  So, imagine this:  you deploy a new application into production on Tuesday, but make sure that the feature flag is off.  When Thursday comes and your boss says “Make it live”, you just need to turn a flag from “off” to “on” and you’re done.  No outage window.  When combined with a more services oriented architecture you have the opportunity to deploy when you want and make features availalbe when you want.

Perhaps you only want a feature available to certain people.  You can do that.  At certain times of the day?  You can do that.  Only to people whos last name contains a vowel in the second character.  You can do that!  Feature flags can ensure that features can be introduced and “backed out” at will, merely through changing a flag.  Imagine a feature not working properly, you just turn it off and the system acts as if it doesn’t exist.

OK, time to get excited.  You see where I’m going with this, don’t you?  By combining (micro)services, a leaner pipeline through the introduction of feature flags, you can introduce new technology very quickly, very easily, and do it using dozens or hundreds of different teams.

Does this work in real life?  Does anyone shop at Amazon?  The used to be monolithic, then they went services.  According to a 2015 presentation they do over 50 million deployments per year across all of their environments.  How do you think they get Amazon Prime day working properly?  Feature flags.  Turn it on at a specific time and turn it off at a specific time.  How do you think they fix problems that occur on a busy day?  Services.  Small changes made to small pieces of code and tested in an automated fashion.

None of this is new, it’s been worked on by some of the biggest companies and some of the smallest companies in the world.  It works.

Adobe Lightroom and Leadership
pixel2013 (Pixabay)

Wouldn’t it be great if you could just pick up an article, read it, and then become an awesome leader? Stosh D. Walsh, a trainer, coach, writer, dude, believes that there are set of principals or rules that you can follow that will make you an awesome leader.  He’s got a big list of these rules, however:

  1. Find your style and inspire
  2. Demonstrate integrity
  3. Finish your homework
  4. Invest in yourself
  5. Manage your brand
  6. Concentrate on the future
  7. Understand people personally
  8. Position people professionally
  9. Praise liberally
  10. Coach and advocate
  11. Forge partnerships
  12. Aske before telling
  13. Anticipate and optimize
  14. Take risks
  15. Expect greatness

I mean, it’s great that he’s got a list, everyone needs a list, but what do you concentrate on, what do you look at first?  The most common thing to do is to tackle the “low hanging fruit”, the easy stuff, the stuff that doesn’t take much effort but still provides valuable improvements. But is that going to help?

Here is a different approach:  pick your worst area and improve that.  It might not be the easiest, but it is probably the most significant area that needs to be improved.  This actually came from a book I was reading on manipulating images from digital cameras.  Highlights in underexposed areas can be enhanced, but if you have something overexposed it is difficult to bring out any detail.  Think of the parts that you need to improve as underexposed pictures.  The detail is there, just hidden in the darkness.  Your job is remove some of that darkness and let the detail shine.

Cool, a photography reference in a leadership entry.

Everything I know I learned in Adobe Lightroom.

Contiguous Time
geralt (Pixabay)

So, your changing context every 10 minutes or so (see yesterday’s note) what impact does that have?

Professor Mark talked about how it inhibits innovation.  Does it?  Or is innovation, creativity, more of an accident than something cultivated and worked on?  Scott Berkun is of the opinion that “Creativity Is Not An Accident“.  He talks about how the stories of people “accidentally” discovering something aren’t really them just stumbling along and – BAM – something hits them from out of the blue.  Instead, their discovery is based on the work that they had been doing to discover something else.  The “accident” was that they discovered something that they weren’t searching for, but they were already searching for something.

The whole process of innovation, creativity, discovery, is based on time.  Not just five minutes here and five minutes there, but contiguous time.  When you have the opportunity to sit down and really think about a problem it takes time for your mind to get in gear, but when it does you are so much more creative than when you try squeezing things in on the side.  For instance, these long diatribes?  Carefully planned out.  OK, not really, but they are almost always written in one session, one continuous session.  And even though I can type like a madman it takes time to write these notes because I am thinking about what I want to say, how I want to say it and whether or not it even makes sense.  (Sometimes it doesn’t, even to me.)  And that also explains why I may be talking about one subject at the beginning but deviate part way through and come to a completely different conclusion:  I had time to think.

The ability to set aside time to think is precious and needs to be hoarded and zealously guarded.  Book a meeting with yourself and leave your desk, go to a meeting room by yourself, visit the library, a coffee shop, a place where you will not be interrupted and simply think about a problem.  Innovative ideas are not normally found in a meeting situation.  They may gain visibility in such a setting but the germ of the idea, the genesis of the solution, was normally done while having some quiet time.

Achieving Flow

"flow", that state where things seem easier, concentration is simpler and you just feel more productive. 
Alelxandra_koch (Pixabay)

Multi-tasking.  Our computers do it and we do it.  But should we be doing it?

There is an increasingly growing body of evidence that states multi-tasking is actually bad for you.  If you are always multi-tasking you never achieve “flow“, that state where things seem easier, concentration is simpler and you just feel more productive.  The colloquial name for it is being in the zone.  We’ve all experienced that, but how many of you have experienced it recently?  A significantly smaller number.

One of the main precursors to achieving flow is the the time and ability to concentrate.  If you are always being distracted than you have few opportunities to achieve this state of flow.  Now let’s talk about how detrimental it is. Continue reading “Achieving Flow”

The Quiet Revolution

A number of years ago Susan Cain wrote a book called Quiet: The Power of Introverts in a World That Can’t Stop Talking.  I personally loved the book as it brought to light many of the problems inherent in being an introvert in an extroverted world.

My daughter has been experiencing this dichotomy in her Spanish class in Junior High.  She is being marked on how much she participates in class.  Wow, talk about something designed negatively for introverts.  By her very nature she is not someone who willingly speaks up in class and interacts with people.  She is an introvert, like her mother and father, and sits back and observes people.  But this is not getting her good marks in school. Continue reading “The Quiet Revolution”