Jan

10

Common Mistakes Teams Make in Retrospectives

Posted January 10, 2012 by Keith McMillan | Leave a Comment

Something has been bothering me about the way I see many teams handle retrospectives. To be fair, it’s really several things. These common mistakes do more than make a retrospective less effective, they destroy any ability to achieve the purposes of a retrospective. Read more

Nov

18

Reconsidering Pragmatic Agility

Posted November 18, 2011 by Keith McMillan | Leave a Comment

I consider myself fairly pragmatic when it comes to agility in software development, or at least I used to… I’m having second thoughts.  As long as I’ve been around agile development (it’s been, what 6 or 7 years…) I’ve been exposed to what some people call Agilistas.  You probably recognize what I mean if you’ve met one: they refer to principal thinkers in the field by first name, and have a tendency to absolutist statements like “there are no project managers in agile, we don’t need them.”  I’m beginning to think they may have a point, just not the one they think they have. Read more

Oct

6

Command and Control by Blog

Posted October 6, 2011 by Keith McMillan | Leave a Comment

Here’s a new method of command and control for malware:

Researchers from Trend Micro have spotted a piece of malicious software for Android that receives instructions from an encrypted blog

In the past, botnets have received their instructions primarily from IRC. This is an intriguing development!

[via ComputerWorld]

Sep

29

The Role of Luck on a Software Development Project

Posted September 29, 2011 by Keith McMillan | Leave a Comment

One of my employees recently said something to the effect of “I think people underestimate the role that luck plays on development projects.” I think he’s right, but it’s a difficult topic to nail down. I’ll give it a try, though.

Read more

Sep

22

What to test?

Posted September 22, 2011 by Keith McMillan | 2 Comments

A couple of years ago, I started working with TDD, and I must admit it’s changed the way I like to work in software. One of the side effects has been some angst on my part on exactly what needs testing… Read more

Aug

24

What’s Done in an Agile Project?

Posted August 24, 2011 by Keith McMillan | 2 Comments

In my time at a major insurance company in mid-state Illinois, we had a very interesting conversation on what it meant to be “done” with a user story.  Done can mean a lot of things to a development team, anywhere from “hey, I just finished writing this code” to “we’ve turned on the feature in production.”

We created what we called a “spectrum of done” to illustrate various levels of “done-ness” (okay, enough with the “quotes”), and to help teams decide where they wanted to be when they said something was Done. Some of the highlights are:

  • Code compiles on the developers machine
  • Code compiles on a continuous integration build server
  • Code passes regression test suite
  • Functionality reviewed by the product owner/stakeholders
  • Functionality deployed into test environment and tested with mock integrations to other servers
  • Functionality deployed and tested with integrations to other real servers
  • Functionality deployed into production
  • Functionality used in production for some period of time

I submitted, only half-joking that we were really only Done with a feature when we turned the system off, because before that it was still subject to change or finding a problem.

There are a lot of reasons why you want your definition of Done to be as advanced as possible, but possibly the most important is that you want the best possible idea on whether you have anything left to do on a particular feature before it can be used in production. Measuring by what’s Done vs what’s not Done requires that you have a diminishing chance that when you say it’s Done, that there’s still something left to do.

The other side of this argument is that we want regular feedback on small chunks of functionality in order to give us regular data points to judge progress, and the amount of time you typically need to invest gets much bigger as you move up the Done scale.  Deploying to production environments in the typical company requires change control procedures, and that means time and money.

The sweet spot for most folks seems to be in building on a shared development server, with some sort of robust suite of tests to assure that new functionality is at least working per the tests, and that nothing that used to work was broken (subject always to the suite of tests being reasonable).  This most folks will recognize as Continuous Integration (although you should really read Continuous Integration isn’t a Tool!)

Keith returns to consulting on 9/1/11 after a year at RedSky Technologies. He’s currently looking for his next engagement.

Apr

13

Spring Framework: good for the gander?

Posted April 13, 2011 by Keith McMillan | 1 Comment

I like the Spring Framework for Java development. It let’s me do all kinds of neat things like interceptors, but fundamentally, at it’s core it lets me break stuff apart to test it in chunks, while still having support for wiring it together to build a complete application.

Spring is all about dependency injection, so you’d think this sort of thing would be easy, and by and large, it is, but every now and again, I run into something that makes me think that someone’s not taking their own advice.  The latest was an excursion into EasyMock and the Spring JDBC transaction support classes. For reasons I won’t go in to, we’re using JdbcTemplate and not something newer like JPA or Hibernate.  In one of my DAO classes, I need to coordinate two deletes, and so I do this:

protected void startTransaction() {

 DefaultTransactionDefinition def = new DefaultTransactionDefinition();

 status = txManager.getTransaction(def);

}

and then carry on about my business. Now, when I want to mock that, first off I need to get a TransactionManager. Well, that’s a class, not an interface, so I have to use EasyMock’s class extension package. Ok, so now I need CG libraries to code engineer a new class extending AbstractTransactionManager:

   DataSourceTransactionManager mockTxManager =org.easymock.classextension.EasyMock.createMock(DataSourceTransactionManager.class);

    TransactionStatus status = EasyMock.createMock(TransactionStatus.class);
    replay(status);
    EasyMock.expect(mockTxManager.getTransaction(isA(TransactionDefinition.class)).andReturn(status);
    mockTxManager.commit(status);
    replay (mockTxManager);

Okay, now I should be good to go. It’s a bit irritating that I’ve got to use cglib to get the mock, but easy enough. Wait a second, what’s this?

java.lang.IllegalStateException: 0 matchers expected, 1 recorded.
        at org.easymock.internal.ExpectedInvocation.createMissingMatchers(ExpectedInvocation.java:56)

Well, it turns out after some poking around, and pulling of hair, I discovered that not only is AbstractTransactionManager a class, requiring me to “program to the class, not the interface” but getTransaction is final, so the cglib override didn’t stick.

Shame on EasyMock and cglib for not telling me my generated class wasn’t going to work, but this isn’t the first time I’ve run into behavior in the Spring Framework itself that makes me think they’re not taking their own medicine, and making it easy for me to inject what I need.

Oct

22

Radio Silence

Posted October 22, 2010 by Keith McMillan | 2 Comments

The astute reader will have noticed by now that I haven’t posted anything in a while… back on September 1, I accepted a position as Vice President of Engineering for RedSky Technologies (http://www.redskye911.com), and it’s been keeping me pretty busy.

I’m going to keep Adept Technologies around, but don’t expect to be doing much with it for a while. I’ll continue to blog here off and on, but getting things working at RedSky is my current number one priority.

Thanks everyone for reading, and keep a look out for the occasional post here.

- Keith

Aug

19

Object Confusion with LINQ to XML

Posted August 19, 2010 by Keith McMillan | Leave a Comment

I’ve been working recently with C#.NET, and in particular had an interesting experience with LINQ to XML. For those unfamiliar with LINQ, the idea is to apply sql-like syntax to a number of areas of the C# language, including XML documents, object, and of course, actual SQL data. Most interestingly, you can combine data from more than one of these sources.  I saw some particularly surprising results when I accessed the resulting collection of objects.

Read more

Jul

16

Security Blind Spot: Ignoring the Physical Element

Posted July 16, 2010 by Keith McMillan | Leave a Comment

I spend a lot of time talking to people about information security. I find that even when they’re interested in protecting their information from theft or misuse, they’re not always focused on the complete security picture.  Today’s case in point is the report [via Gizmodo ] that thieves spent NINE HOURS stealing laptops from a government contractor, loading up two semi tractor trailers with computers before making their escape.

It does little good to pay attention to digital security if your physical security is weak. Security needs to be treated in a holistic fashion in order to be effective.


Blogroll