David Kramer’s high-entropy blog

Resisting the urge to do more

As a Software Engineer and as a geek, I face many tempations.  One of them is “I can add this really cool feature while I’m in the code, and it will take hardly any extra time.  It won’t impact any of my other work at all”.  There are some very good reasons why you shouldn’t do it though, and why it’s an Agile anti-pattern.

  • Most people are bad at timeboxing, no matter how good their intentions are. I know I find myself adding “just 15 more minutes” to timeboxes more often that I should.  You may be spending more time on these extras than you think, or at least more than you intended.
  • You are part of a team.  The extra work you do may not create much burden on you, but it may create a burden on others.
  • If you have extra capacity, there may be much more valuable work you could be doing.  It might even be just as quick.
  • Who is going to QA your work?  Is extra documentation needed?  Do you even think about the documentation needs?  Are extra configuration options needed that Release Engineering needs to coordinate?
  • Every line of code is the potential site of a bug, conflict, or incompatibility.  Maybe it works now, but interacts with other code or data that it breaks.  Maybe it breaks in the future.  Maybe it has a performance impact (since this work didn’t come through normal channels, it probably wasn’t accounted for in performance testing).
  • One of the Agile principles is that decisions are made at the last responsible moment.  By doing work that did not result from a team decision, you make design and implementation decisions that may no longer be appropriate when that feature planned.  Depending on how much work it _really_ was, you may be locking the team into a suboptimal path, or at least creating extra work to remove your implementation
  • Most forms of Agile focus on the team functioning together, self managing and empowered, and acting as one.  When someone takes it upon themselves to do work that wasn’t planned by the team, it can affect the team dynamics just as much as if someone said they would do something but didn’t do it.  It breaks expectations about what is happening and the flow of work through the process.

I’m glad Microsoft is embracing open source

When someone, especially new software developers or those still in college, asks me whether they should learn Java or C#/.NET, my normal answer is something like “They both do about the same thing, but Java will run on almost anything, and almost all the development tools are free.  With C#/.NET you could pay hundreds for Visual Studio, and the programs will only run under Windows.

Microsoft has a long history seeing open source as the enemy, but has never had a problem stealing ideas from it. They even use marketing jargon that is directly opposite of reality.  My favorite case of this is Microsoft Windows Services for UNIX, which is actually UNIX-like utilities you install on a Windows computer to give it UNIX-like functionality, not something you add to a UNIX box to help it communicate with Windows.  In the past Microsoft has even called Linux a cancer.  These days they’re singing a different tune, one that goes “We love open source“.  We know what the motivation is.  In the real world, business computing environments are of mixed architectures and operating systems.  Everything needs to interoperate.  They’re not going to dominate the server world like they do the desktop.  But you know what?  I don’t even mind that they don’t mean it as long as they act like they do.  And they are.

Microsoft is opening up major parts of the .NET codebase to open source.  They’re doing so under the MIT license, not a GNU license, and that makes sense.  They’ve made major contributions to Linux in the past decade.  There’s also now a community edition of Visual Studio so you can use it for learning and some projects for free, which is long overdue for them.

I’m a Linux lover, not a Microsoft hater.  Any steps they take in the right direction are OK by me!

Lack of accountability will break ANY process

No matter what your process, and how good that process is, lack of accountability can limit its effectiveness, and the effectiveness of your organization as a whole.  Any model will fail to be accurate when it does not represent reality close enough.

Let’s say your company is using Scrum to manage software development work.  If you have people on your team that regularly do work that’s not on the scrum board, it hurts the effectiveness of the process because

  • The unplanned work being done isn’t being tracked, so resource planning and allocation will be off
  • Part of what makes Agile work is you’re doing the least work required to meet the objectives (when the unit tests pass, stop coding).  Software Engineers often face the “Wouldn’t it be cool if it also did X? This will just take a minute to implement” temptation.
  • The unplanned work being done may not even be desirable or valueable to the Product Owner.
  • The unplanned work may actually hinder further planned work by taking the application in a different direction or prematurely locking the application into a design implementation that may become invalid in later sprints.  This is in conflict with making decisions at the last responsible moment.
  • The unplanned work may become a burden to others.  Either QA finds out about it and has more testing work to do than planned, or they don’t find out about it and any bugs in it can escape into the wild.

Read on…

Where does your power come from?

Equality as a true/false condition doesn’t happen in the real world.  It’s not only a continuum, but people can be equal in some ways but not others.  Attempts to change this even in science fiction always end badly.  Even if everyone were completely equal physically and mentally, a well-functioning society requires some sort of hierarchy, because everyone can’t know everything, take everyone else’s concerns into consideration, and agree on courses of action.  That’s as true in the federal government as it is in a family home or at the office.  Can you imagine a large society where everyone voted on everything?

The question is, how do the people at the top (or even the middle) get there?  How do people gain authority over others, how do they keep it, and why do the people who they have authority over listen to them?  What do they do with their power?  These all vary greatly in implementation and degree of fairness.  As you read this, please keep in mind that I don’t treat “power” itself as a bad thing.  How one gets it and what one does  with it may be, though. Read on…

Teams Need To Work Together

I just read an interesting article from DZone called There’s No Such Thing As A “Devops Team”.  Readers who have been around a while will know that a flippant title like that is neither going to be totally true, or even the real point of the article.  And they would be right.  The real point of the article is that silo groups are bad, and silo groups that don’t talk to each other are infinitely worse, and the bigger the [real or imagined] barrier to them communicating, the worse it is.  The solution to two teams not working together (in this case the developers and the operations/release engineering group) is rarely to insert another group between them.

Read on…

Keep IT Systems Simple

There are a lot of technology options out there.  There are even a lot of free/open source technologies out there.  So much so, that it’s tempting to install too much of it.  Having too much technology can be just as bad as having too little, and “free” can become pretty costly.  Obviously I’m not knocking free/open source, but the misapplication of it.

First and foremost, the more software/hardware you have, the more likely it is that some of it will have a bug.  That’s just law of averages coupled with the fact that no significant software project is really bug-free.

Then there’s the maintenance effort.  The more technology you have, the more effort needs to go into care and feeding of it.  Also the more you have to learn about.

Lastly, just how Agile teaches us to delay decision-making and development to as late as possible, because that’s the point where we know the most about what’s needed, the more technology you put in place before you need it, the harder you make it to implement what you really need when you do.

Read on…

Next Page »

Site info