Posts by Matt Stephens

Frameworks and the danger of a grand design

@Rich and Ivor

Rich - nothing revolutionary about this, as the article states this is a "growing pain" that we all tend to go through - obviously the earlier in your career the better.

On frameworks, the key is in this part of the article immediately following your quote: "But sometimes, you do want code to be re-usable because you can see exactly where it'll be re-used. ..."

(In other words, use a framework if you must - think Occam's Razor).

Ivor - If there's damn fine money to be made, I must be missing a trick somewhere (I'm just in this gig for the groupies anyway ;)

Hafta Man and the threat to agile design

re: Hafta is what you hafta do most of the time

Jim: Yes and no. Yes, no-one said it would be easy. But when you're dealing with sub-par interfaces, those are the times when it makes sense to rattle the cage even louder.

I really didn't follow your second point: In an ideal world you wouldn't want unmaintainable systems that don't work together. So if everything is genuinely built using the ideal world, you'd end up with the opposite: maintainable systems that talk to each other nicely.

re: real world + third party api = hafta

That's a fair point, the rules change when you're talking about making demands on the gold-owning client. Ultimately it's their project, they can have the bread buttered around the edge if they want: as long as it's in writing that they're going to have greasy palms afterwards.

Having said that, a client relationship isn't (or shouldn't be!) totally one-sided. You need to be able to push back a bit.

Don't unit test GUIs

James: "little bit of visual inspection"

Hi James,

Visual inspection implies a lot - creation of test cases, regression testing, steps to recreate known issues/prove fixed, etc. It's a whole bunch of stuff that I didn't mention in the article because that isn't what the article is about.

But I agree that the front-end should be tested, and tested extensively: just that given its nature, automated testing isn't necessarily the most effective way of doing it. Robots/automated UI testers don't spot visual errors in quite the same way that humans do.

I disagree with your point that "the ONLY thing that people ever will see is the Swing Gui". The data that you see in lists, tables, plus any other application state, comes directly from the model, which should be heavily unit-tested......

re: Swing doesn't promote separation of GUI and logic?

Chris,

Yes, separation of GUI and logic was one of the theoretical design goals of Swing. In practice, people tend to put app logic directly in the event listeners, which end up as anonymous inner classes inside a class that extends JPanel (or whatever). I've seen it over and over at many different companies. The example code in the article is an example of how the logic creeps insidiously into the GUI code. It's so easy to add a quick validation check into the listener, until very quickly the whole app ends up that way.

As for Swing models, much of the model code tends to be "plumbing" code, e.g. a custom TableModel can contain just as much mechanical stuff to do with responding to user actions and notifying the UI of changes, as business logic. Swing models are not true business domain models. You end up with a class that doesn't really know what it is (is it a Swing mechanism or a business class?), again difficult (though not impossible) to unit-test. Making sure the logic is separated into dedicated classes just makes this sort of thing easier.

Vague and ambiguous use cases

Vague and ambiguous use cases

Thanks for all the feedback. I guess I should point out that the concrete, tangible use cases I've described do make sense (at least to me!) in the context of the overall development process that we described in the "Use Case Driven" book (i.e. the "ICONIX Process").

The reasons it makes sense are that:

a) the team will be working from a higher-level set of functional requirements ("the system shall..."), and the purpose of the use cases is to create a more grounded specification, i.e. it's time to nail down the specifics;

b) in the process of writing the concrete use cases, you would also be delving into preliminary design; so the developers would definitely be involved at that stage. So for example, they would have plenty of opportunity to say "hang on, the system just wouldn't assign an ID there, it would be part of an overall transaction" so the preliminary design, and therefore the use case scenarios, get a serious reality check before the detailed design work begins, and it gets everyone thinking about how (and whether) the system as specced is really going to work; and

c) the analysts can be assured that the developers fully understand the requirements, i.e. that everyone is "on the same page".

The perils of pair programming

re: Books and sh**

Doug was referring to an article that I wrote back in 2001. The quote was concerned with a tendency in XP culture (at the time) to rebut criticism of the process by saying "Have you even tried it?" A bit like saying "How can you possibly say that jumping off a cliff is bad if you haven't tried it?"

For the record, it was a couple of years after the article appeared when we wrote the book. Like most developers, though, I've pair programmed on & off throughout my career (both in agile and not-so-agile projects), as the occasion calls for it.

re: Did you really read the book you're talking about?

Marco,

I guess you need to keep in mind that the article isn't a critique of PPI; nowhere do I say that I disagree with all the points made in the book -- therefore it shouldn't be too shocking if I agree with them from time to time. :)

One of the good things about PPI is that it discusses the problems associated with pair programming; but they're still problems.

Your comment in point 2) is a fair comment; I oversimplified the case on that one.

Thanks for the feedback,

Matt

Thought-provoking feedback

Thanks for all the feedback, it's definitely food for thought.

I'm in agreement that pair programming can be highly beneficial for knowledge sharing, continuous code reviews, that sort of thing; with the caveat that the pairs are actually suited to constant pair programming (not all programmers are; but that doesn't make them bad programmers).

But pair programming appears to have a law of diminishing returns if it's done ALL the time (not counting XP spikes which tend to be solo-coded anyway, of course). The alternative to constant pair programming doesn't have to be (and really shouldn't be) "constant solo programming". Some hands-on team leading, regular design discussions around the whiteboard, occasional pair programming, shared (and continually updated) domain model, project wiki, mentoring junior coders etc, can work wonders for knowledge sharing and code quality, without the added overhead of two programmers working on one program (I know I'll regret mentioning that!).

(Quick note on mentoring junior coders: not ALL the time, obviously. At some point they'll benefit from cutting the apron strings, heading out into the scary world of solo coding, thinking for themselves, learning without a "security blanket" there to tell them it's okay. Mentoring==good, mollycoddling==bad).

Naturally, if you work in a pair programming team and you enjoy it, best of luck to you: don't change what isn't broken. It just isn't for everyone or for every situation.