mike.mainguy

Having lived through numerous attempts to build software embracing the concepts behind the agile manifesto , I feel there are three large categories folks fall into when talking about agile principles. The curmudgen - these folks have been writing code since punchcards where the state of the art, OR they have been brainwashed by large consulting organizations into thinking that a large heavyweight process is the only way to succeed. Note, a subset of these folks believe that "no process" is actually OK and are quite happy to cowboy-code their way through life. The fanboy - these folks think "everything agile all the time" and will rename status meetings to "scrums". These are folks who are used to working solo on projects that they can do in their heads... or they are simply not clued into the implications of actually having a repeatable process or delivering working software. The apologetic - these folks understand the principles and the value they...

Yesterday I posted a somewhat snarky comment about how You don't need layers until you need them which may have seemed like a nonsensical thing to say. Today I was started to write an example of how to refactor an anemic data model with lots'a layers into a lean and mean persistance machine... but stumbled into a perfect example of what I was trying to say. In essense, I was trying to repeat the idea that "Ya Ain't Gonna Need It" , but with emphasis on the fact that... Yes, you may KNOW you're going to eventually need it, but building infrastructure before you need it accumulates overhead that you must pay for, even if you don't get the benefit. My Example (Snippet of pom file) <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 htt...

I've written in the past about change control processes and how they relate to agility. Taking things to the next level, there's a bigger issue that needs to be addressed. There are essentially two radically divided camps on what value IT Governance provides for enterprise software. These camps are: #1 the business camp which is tired of hearing excuses about why they are losing millions of dollars of business because IT cannot deliver a solution in a timely manner and #2 The IT camp that is tired of the business camp requesting crazy stuff and causing millions of dollars of unnecessary support costs. Camp #1 thinks governance is an excuse for IT/process wonks to slow things down or foot drag instead of delivering solutions. Camp #2 thinks governance is a way to reign in the business folks who believe that unicorns and pixie dust cause fully configured computers and network infrastructure to magically appear over night. I hope its obvious that both camps are spectacula...

I've found the term "best practices" to typically be a magical incantation that people invoke to use a fictitious third party expert to support their position. When most people say "best practices dictate" they're really just saying "because I said so" and I meet them with extreme skepticism. This is not to say that the idea of "best practices" isn't alluring. Wouldn't it be great if we could simply do things the "best" way and not have to think about what we're doing. In fact, sometimes it might be valid, for example a "best practice" in java is to follow a naming convention. The first letter of classes should be upper case for example. I think this is reasonable, but frankly I'm currently hard pressed to understand WHY. If you're going to recommend best practices, I feel you have an obligation to be able to explain the NEED of the "best practic...

Fact: putting a skirt on a Gorilla doesn't make it any more graceful Are your agile initiatives Gorillarinas? If you're working in a large organization and trying to "be agile", it often turns into a strange situation where only a superficial set of changes are made, but folks wonder why their initiative isn't able to deliver the expected benefits. This is remarkably similar to putting a skirt on a Gorilla and then wondering why it isn't suddenly graceful. I'm not saying you cannot train a Gorilla to dance ballet, I'm an optimist at heart and believe anything is possible. But don't make the mistake of thinking that the effort of taking an IT organization that has built up the overhead gunk and crud of a huge process and turning into a highly responsive and lean software delivery organization is anything less difficult than turning a Gorilla into a ballerina. This effort will be large, there will be casualties, and you will likely need ...

My short answer is: "very". My Long answer Follows: Devops is a reaction to a common problem in software development. It's referred to here as a "wall of confusion". I've blogged on this before and anybody who has ever worked in a shop with two different teams (ops vs dev) you will likely understand the problem very well. Inherently, Ops wants stability and dev wants change. I believe the recent push for "agile" in IT organizations has aggravated this problem to an extreme in some places. This aggravation has been because the focus of agile has been on the DEVELOPMENT of software, but not the OPERATION of software. To clarify how these responsibilities are typically divided: DEVELOPMENT Perspective Make new features for customers Get it done quickly Get it done cheaply Move on to next thing Don't worry too much about the future or past… Live in the NOW OPERATIONS Perspective Fix the messes created by development Prevent ...

I just stumbled across a great article about the difficult transition from a startup into a more sustainable business. The elves leave middle earth I'm currently working in a place that is going through this change in the IT organization. Right now, we have a mixed team of heros and good performers. A key problem I'm having is that one of the managers is having a tremendously difficult time even fathoming the difference between these two modes. As a former hero coder, he spends his time fiddling around with code and inventing new "cool" requirements and almost zero time even thinking about how to keep the team performing. This has the predictable side effect of the team faltering and thrashing while this person sits around and bemoans how slow and confused the team is. Where I'm going is that if you're going to decide to change modes, you need to make sure you have a management team that is able to function in that mode. If it's necessary to move folk...