I love learning new words, especially if they help to explain something in a way that I never thought of. For instance, let’s take the following word:
idempotent: the property of certain operations in mathematics and computer science, that can be applied multiple times without changing the result beyond the initial application
Or, at least, that is what Wikipedia says. But, what does it really mean? Suppose you had a function that updated someone’s birthdate and you called it with the value ‘1984-04-03’. Afterward, that person’s birthdate would be ‘1984-04-03’. It wouldn’t matter how many times you called the update function, the value would still be the same. Reading data is an idempotent operation as no matter how often you read it the values are the same. Continue reading “Batch Processing”
How many of you guys run projects or are involved in projects? How many of you run maintenance or are involved in maintenance? (Yeah, I read my own note from yesterday.)
So, that’s a lot of you. I bet that a good portion of you are Agile projects that use sprints. Did you know that an Agile project doesn’t necessarily contain sprints? Sprints are a Scrum concept that many Agile projects have adopted. But have they adopted it properly? How many of you realize that at the end of a sprint you need to have an application that can be deployed? Wow, the number of hands that dropped was amazing. Let’s get some definitions out of the way first: Continue reading “Agile Is Not Another Form Of Waterfall”
OK, here is the discussion about maintenance versus development. I mean there are hundreds of things that are different between maintenance and development right? I mean maintenance needs to keep track of source code and development … well, developments need to do so as well. OK, how about resourcing? I mean maintenance for a year has a defined start date and a defined end date and a certain amount of resourcing. Development teams? Well, they have a start date, an end date and a certain amount of resourcing. OK, but maintenance deals with small things, five or ten-day tasks and development deals with larger things and that’s different, right? RIght? Continue reading “Maintenance vs Development”
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”
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”
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.
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”
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 againstCOTS 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?
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.
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:
Find your style and inspire
Finish your homework
Invest in yourself
Manage your brand
Concentrate on the future
Understand people personally
Position people professionally
Coach and advocate
Aske before telling
Anticipate and optimize
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.