I was driving home from work and a car in front of me went from the right lane to the middle lane, to the left lane and turned, all in the space of twenty meters. I was quite surprised at how late the person was at understanding that they needed to be in the left lane. A couple of blocks later someone else did the same thing. Closer to home? From the left to the right lane and turned but they forced the bus to stop as they weren’t really in the right lane at all when they turned.
Let’s assume that you are part of a project team creating a new product – The Whizbanger – and you’ve just completed your major release. It’s in. It’s complete. What’s next?
Well, in some organizations, the product is passed off to the maintenance team. But you’re in a progressive organization where the product team does everything: all major releases, minor releases and bug fixes. So the next step is obviously to fix bugs and work on the next release.
Oh, you’re not in progressive organization? That would mean that you are handing off the application to a maintenance team that will do bug fixes and perhaps minor releases while your team … works on the next major? Continue reading “How Many Environments Do You Need?”
Tightrope walking is a dangerous thing. So is changing an existing process or doing something new at work. People are scared. Too scared to even try. But it doesn’t have to be. People need to be able to experiment safely. Innovation is inherently dangerous and without people willing to try it will never happen.
Zappos CEO Tony Hsieh, said in an interview that the bar for trying things is this:
Is it safe enough to try? It doesn’t matter if other employees think it’s a bad idea. I can take that input. But is it safe enough to try?
(For more details look at this article on LifeWire)
If invoking HTTPS is as simple as HTTP, why would anyone use HTTP? In Google’s opinion, no one should be. When Chrome V63 is released a new feature will be running that is going to scare a lot of people. When you visit a website that contains Form fields, but is not running HTTPS then it is going to tell you that the site is Not Secure. Will it scare you? It should.
At what point does a “data fix” do more harm than good? For that matter, what is the tipping point between doing a data fix and fixing the application? A data fix is merely a bandage for an application. It treats a symptom, not the problem.
There are many debates about this very topic but let’s get things settled at the beginning: one data fix is too many. Yes, that seems rather draconian, but if you need to go into the database and manipulate the data to achieve the correct business results then there is a failure somewhere in the process. Perhaps it was in gathering the requirements. Perhaps it was in not providing the correct testing. Or perhaps it was an unforeseen circumstance. (The users got access to the applications. It could happen.)
That all depends on which side of the fence you are standing. If you are developer things are simpler. If you support DevOps, if you are one of those people that is trying to automate processes or make things simpler for others, then your life is more complicated. Instead of one tool you’re dealing with many tools all hooked together with bubblegum and twine.
I entitle this note “The Fictitious Difference Between AMS and ADS“. (AMS = Application Maintenance Services : ADS = Application Development Services or something similar). Now, from an organizational perspective there may indeed be a difference when it comes to how the changes get funded. One may be capital funded and the other operational. Or it may be that there is a cutoff in terms of the effort: less than x days of effort it is maintenance but over that it is a development effort.
My real concern is over how people seem to treat AMS and ADS as different things. One is managed in a certain way while the other is managed differently. One follows different steps than the other. One uses different processes/procedures than the other. One may even use the tools differently. But why? Continue reading “Maintenance versus Project work”
Embed from Getty Images
According to Forrester, “modern software delivery practices use an automated pipeline in which code is delivered, built, tested, and deployed with limited manual intervention“. (TechRadar: Continuous Software Deliver, Q3 2016 (Updated)). Indeed, this modern pipeline means that “Continuous Delivery (CD) is Replacing Application Life Cycle Management (ALM)“. So how different is continuous deliver compared to our old manual processes and even the processes that we have put in place with our automation tool: BuildMaster?
Under the old way of developing applications the developers would build some code, test it on their workstations and when a bunch of code had been checked into the code repository, a build would occur. This build may or may not be deployed to a System Test environment for someone to do some manual testing. After it passed the same package would be moved to the User Acceptance Test environment where it would be tested by business clients. If it passed it went to production. If it failed it stated the process all over again. This is why La Sagrada Familia is still not finished. (OK, it’s not but it gave me the chance to link another site to you.) Continue reading “Continuous delivery”
For many years, I have observed that the quality of software produced by organizations is a decreasing function of their emphasis on project management over business value creation-that is, their obsession with predictability and efficiency over learning and adapting.
Sometimes we need to think long-term. Unfortunately, in the government, long-term normally means “next fiscal year” or maybe even “next quarter”. But that’s not long-term enough. Let’s take a look at an example of where thinking long term, even in terms of the government long term, will have an impact on what we do right now. Continue reading “Privacy By Default”