The Perfect Project

While dodging cars and fighting the wind (I ride my bike to work), I started thinking about what components make for the perfect software development project.

Valauble Business Problem
Business Problems fall into two categories. Those worth solving are one, everything else is another. What makes a problem worth solving? One of two things happens when the system goes live: Money is saved or money is made. One of these should present itself within the first quarter of the code going live. Asking a client to wait longer than that means the project was likely too large in the first place, it should have been reworked. A perfect Agile project would have the business measuring money saved/made from one iteration by the time the next iteration is lighting up.

Easy Access to the Business Experts
I think this one is more common than people think. If you’re about to solve someone’s problem, they want to help. Now, they’re never keen to help you solve a problem not worth solving (see above). A legitimate problem? Everytime.

An Agile project has different demands on the Business Expert, they are asked to behave differently. I have never experienced the Business Expert shy away from this. You are asking them to help you help them. Maybe this post will lead to me meeting a Business Expert from hell, keen on ripping my head off for not knowing how Credit Liquidity or Risk Management work…

Open, Dynamic Team Members
My current project fits this in a lot of ways. Lots of people wearing lots of hats. Business Experts reading API docs and writing tests, Developers meeting with management to discuss ROI — an absolute pleasure. Everyone has interests outside the project: another key. Work is something you do from Monday to Friday, morning to late afternoon. I’m much happier discussing various hikes or how my Leafs did last night than how some developer worked all night on a problem they could have fixed had they discussed it with the other team members. Leave your ego at the door, we all make mistakes, we all miss stuff. When you stop thinking people expect you to be perfect, you’ve taken your first step in perfect’s direction.

Flexible Approach
If the requirement is moving people from Canada’s east coast to west coast and the year is 1871, yeah, not so flexible. You’re building a railroad and that’s that.

It’s 2005. An infinite number of tools to solve the same problem exist. Try one. If it’s going to work, use it. When it stops working for you, change. If change means going back over work that’s been done and refactoring it, do it. Changing your code doesn’t mean it was wrong the first time through, it just means you’ve found a better way of working the problem.

Maturing into technology

I think a career is comprised of steps. Some are small and some are quite big. The small ones tend to be more tangible, things like learning a new language, a new design pattern or some new tool. While they seem big at the time, really, they’re just newer ways of doing something you’re already trying to do. Still a step forward, just a little one.

I think the bigger steps are also changes in the way you do things, just on a much higher scale. Test Driven Development would be an example that comes to mind. Still writing code, just changing the way I think about it.

Maybe that’s a bad example…no, that’s a bigger step than using, say Eclipse, instead of Visual Age for Java but still not a BIG step.

I don’t really have an expression for them but two big steps have come to mind recently. The first is the notion of getting others involved in what you’re working on. I see (and used to be) so many software developers working within their own little world. They sit at their machine and cut code all day. Agile is supposed to alleviate this a little, getting customers involved (a great idea) but leaves an element out. The developer in that case is often still left with a screen full of their own code. Pair Programming is a start, but it’s still missing the step. The step I’m referring to is when a developer wants other people in their code, wants their peers to see what they’re doing. Code Reviews fail in this respect in the same way as pair programming: it’s usually someone else’s idea. Yep, a developer (or at least this one) should want people to look at what they’re doing. Developer’s should stop looking at what they do as being the trade putting insulation behind the gyprock. Developers need to see themselves as (using the same metaphor) cabinet makers (or any trade with a precise skill under constant scrutiny).

That’s the first one.

For the second step, you need to listen to a little story. I’m an alumni of NOLS, having spent time kayaking with them in the Sea of Cortez. The most significant lesson I learned on those travels was the concept of Leave No Trace (lnt). A lot of the lnt princicples can be applied to software developmet. What are some “traces” that I would consider trying not to leave?

-Major server configuration changes
-Additional memory requirements
-newer hardware
-container classpath changes

This list could go on forever. By trying to apply lnt principles to software development, the developer needs to use their mind to devise creative ways around environmental constraints. This way their application can be moved from server to server and deployment won’t be an issue. Deployment can just happen. The tents come down and the next camper doesn’t know you were there (so to speak). I want to continue trying to make this step. With the falling costs of disk space and memory, the temptation will always be to write less efficient code and place the burden on the infrastructure. tsk, tsk I say. Chopping down one little tree does have an impact.

To summarize: Invite lots of people on the camping trip and leave the campsite looking like you were never there.

Remembering Memory Management with CORBA

Java is a wonderful language, especially when compared to a container native language like LotusScript. There are many more options, frameworks, design patterns you can play with. The tools for writing Java agents make the days of writing LotusScript agents seem like forever ago. Have I discovered the silver bullet in the Domino world? Is this my valhalla?

No.

Not by a long shot. Remember memory management? Yeah, it’s back. I tried writing a simple agent that processed a Domino view containing a little more than 20,000 records. The agent uses the POI framework to convert the view into an excel workbook. This is done on a nightly basis. Here’s the thing. Domino’s default heap size is 64mb. My agent was running out of memory. A simple increase in heap size got me around the issue but raised the concern that memory management is something I now need to keep my eye on when writing these Java agents. I know, I know, any (every) developer should always be thinking about memory management but Domino’s LotusScript lulled me away from the concern.

That being said, I still believe this is the way I’ll continue to write my Domino agents from this day forward. My main reason? I can write junit tests for them. A topic for another day…