1&1 Quality Issues

Uncategorized

So, the Pittsburgh .Net Code Camp’s web site (http://pghdotnet.agileways.com/) has been down since last Friday (3/13). The site is hosted by 1&1. 1&1 has a 99.9% uptime guarantee. That means that in the course of a year, no matter what, they think that your site won’t be down for more than a total of about 9 hours (actually 8.76, but who’s counting? :)).

The site has been down for over 100 hours. Calls to support are not getting anywhere. All of the sites on that account are down (note- its not my account).

I’m not saying you shouldn’t host with 1&1. I’m just saying you should know what you’re getting in to…

Advertisements

“Design”

Uncategorized

The team I work on has been doing “scrumbut” for a while, and now that we are wrapping up the current project, we are trying to figure out how to fix it and do scrum going forward. In that context, I wrote this email to the team (why was that my job? I’m one of the technical leads…). Note that the “company across the parking lot” is Westinghouse – they build nuclear reactors – I hope they do a lot of big design up front! Also note that much of this idea stems from reading and digesting the works of Scott Ambler, particularly this one. Enjoy:

So, we still want to do Scrum. And plans are underway to get us back into the swing of it. Well, there are some things we didn’t do real well the last time around, and many of them have been identified. One thing we didn’t do very well at all that I’d like to address is “design”.

To some people, design means writing a 100 page document describing every possible thing that could happen on one simple data entry screen. That probably works fine over there across the parking lot, but its not particularly agile, so lets abandon that thought.

To other people (and the way we worked in 7.0 [our current project]), design means “I thought about it for a couple minutes, lets sling some code”. That doesn’t work very well, either. Sure, you can make things work, especially in the simple cases, but then most of the time you end up with stuff that is hard to follow, and isn’t optimal (in terms of any of the ” –ilities”: maintainability, scalability, readability, etc.).

So, what is the answer?

When you get a task that will ultimately result in writing code, you should sketch out what you plan to do. If it’s a simple feature (say, something like a data entry screen for something simple, like maybe a unit description), doing this exercise in your mind is probably sufficient. If it is a little more complex, a “napkin sketch” of any sort that you prefer (actually doodling on a napkin, drawing a little on your whiteboard, making a TODO list in notepad, etc.) is sufficient. Just make sure you don’t put a lot of time into it – its probably disposable.

Regardless of how you do it, keep in mind that collaborating on a design is not a bad thing. We’re not in college anymore – working with others is not cheating. Get in the habit of getting together with someone else and discussing your design. We’ve got whiteboards around (granted, the ones at our desks are entirely too small, but better than nothing). There’s plenty of paper in the supply closets. Get together and draw and talk.

What if you need to implement a hard feature, like ClassifyRequest, for example? I’d recommend using as little prose as possible – it gets hard to maintain. I’d suggest you create UML diagrams – especially Activity, Sequence, and State diagrams. Design documentation for a feature like this needs to live on, so it needs to be as easy to maintain and modify as possible. The huge, ugly design documents we write don’t satisfy this requirement. They are pure shelfware, in a totally Big-6 (or however many of those worthless huge consulting firms are left) kind of way. The alternative is to draw diagrams – a picture is worth a thousand words. Diagrams are generally clearer than prose, and far easier to maintain. They also help you resist the urge to get TOO detailed. Details at the design level are generally not helpful – the well-written code itself is the best way to define the details.

If you don’t know UML (or need a refresher/reference), this site seems pretty decent: http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/index.htm. Don’t worry about getting it perfect, especially if its just a whiteboard sketch. As long as you’re close, people will be able to figure out what you mean.

So, going forward, we need MORE design. But we need the RIGHT KIND of design. When you think of a tool for design, think whiteboard or Visio, not Word.

Another Manifesto

News

All these manifestos to sign – I’m starting to feel like I’m selling out my quasi-libertarian belief system. 🙂

Seriously, though, another software “contract” that makes sense – its really an extension of the Agile Manifesto: The Manifesto for Software Craftsmanship. It make sense to me – we are letting ourselves, our peers, and our projects get burdened down with massive technical debt. Time to resolve to stop letting that happen. Go sign it now!