Jan
10
Common Mistakes Teams Make in Retrospectives
January 10, 2012 | 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
November 18, 2011 | 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
Sep
29
The Role of Luck on a Software Development Project
September 29, 2011 | 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.
Sep
22
What to test?
September 22, 2011 | 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
Apr
13
Spring Framework: good for the gander?
April 13, 2011 | 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.
Aug
19
Object Confusion with LINQ to XML
August 19, 2010 | 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.
Jul
7
The Folly of Password Standards
July 7, 2010 | 1 Comment
I was out on a web site today, it doesn’t really matter which one, and was forced to create a profile for the (mis)use of the site’s owner. I found their password standards to be, well “stringent” would be a good word, especially considering the information (my profile) that I was securing. Their standards for passwords were, and I quote: Read more
Mar
1
Just Enough vs. Just In Case
March 1, 2010 | 8 Comments
It’s amazing to me the lengths people will go to in order to have something “useful” to do at work. The problem is, in their quest to have something to do, they tend to make more work for, and slow down, the rest of us. Read more
Jan
26
Is it Agile, or Chaos?
January 26, 2010 | 4 Comments
Every so often I’ll run into a product owner, project manager or other stakeholder who thinks that “agile” is the best thing since sliced bread. But it’s not really for the reasons you’d consider healthy. “We can change what we want at any time, because we’re being Agile!” they say. Read more
Jan
5
Temptations of an Agile Project: But that’s Easy! Can’t we just do it?
January 5, 2010 | Leave a Comment
Some ideas that seem perfectly sensible are really disasters waiting to happen, and agile teams are not immune. I’ve started to notice some frequent mistakes that inexperienced, and sometimes not so inexperienced, teams make when they’re trying to be agile. These things seem like perfectly good, common sense ideas, but they have undesirable consequences, and we’re going to see what those consequences are.
Sometimes teams get too enthusiastic, and while enthusiasm is a good thing, it can get out of hand. The temptation to add additional bells and whistles to a story in the sprint backlog can be a temptation that’s hard to resist, but resist we should. Why, you ask? Read more
keep looking »Blogroll
- Ars Technica
- Dark Reading - IT Security
- Help Net Security
- InformIT
- SANS Internet Storm Center
- Schneier on Security - Dr. Bruce Schieier’s blog
- Security Info Watch
- What to Fix - Daniel Markham, fellow consultant
- Wired Gadget Lab
- Wordpress Documentation
- WordPress Planet
- Wordpress Support Forum
