How to Explain This

Draw a picture.
If you think you're too smart to need to, you're wrong.
If you think Joe over there understands what you're saying, you're wrong. You should draw a picture.
If you think you understand Bob, you're wrong. He should draw a picture, write it down, look at you and ask, "you know what I'm saying?"
My basic rule is if a design requires me to stash things in little cubby holes in my brain while someone is explaining it, words alone won't cut it. Example: "a queue is going to hold 50 items, and it's implemented as a table, so we need a stored procedure to update the date if it's already there, otherwise we'll insert --" STOP. Draw a picture, man, PLEASE.

If God Raced a Motorcycle

He'd be Valentino Rossi. He wouldn't have to create the supreme motorcycle racing being, He already has. Rossi wraps up yet another consecutive world title when it seems the machine doesn't even matter (his Yamaha was and may still be inferior). The competition can't keep up. He passes people at will. What can you say? Sure, God probably wouldn't have dumped it by colliding with Melandri at Motegi (OK, definitely would not have), and God would have won at Laguna Seca and Malaysia somehow. BUT, do you think He could have pulled off that win in the pouring rain at Donnington? No, at least not any better, probably. Maybe.

I try to keep things focused on software development and related biz stuff, but Rossi is The Man. Surely there's a way to relate this to this blog's purpose, but since it's mystifying how he does it, it may forever be disconnected from any reality.

Forza Rossi!

The Tuna Speaks Management

Bill Parcels last week, commenting on Drew Bledsoe and Keyshawn Johnson having a sideline spat vs. Philadelphia after a dropped pass:

No, that was nothing. I mean that's nothing. Really, it's nothing. Those two high strung guys -- Actually I had told the team the week before or two weeks before: Hey listen if you don't trust each other enough to air out your differences, you are never going to have a team. If you are afraid of conflict within the team and afraid of confrontation within the team, you are never going to have a team. That's not a team. That's a bunch of guys soaking around wondering what the other guy is thinking. So, I am not saying that I encourage that, I tell them that you have to trust your teammates enough to be able to say what you want to say. If you don't do that, then you are never going to have a team. I have always believed that. You guys know from the teams I had. They weren't exactly uninhibited.

Why would I care about what Parcells has to say? His career has all been downhill since his greatest gig as coach of the Giants. Well, he does makes sense. So much sense:

Say what you think -- really, SAY it
Be in an environment where that is accepted
Hear it, digest it, move on
Use it to get better

How many places are out there where being professional means keeping your mouth shut? Or couching your point in well-laundered language? Or softening a meaning when it's said about the boss? Or working at a place where everyone wants things placid and coated in a smooth, white gloss? Where dissension is an evil thing?

I don't mean we should all be loose cannons. I just believe there is more to be gained by being frank at critical moments rather than holding back. The people will smooth it out between and among themselves, the organization will benefit.

My my my, This is Cool

Placeopedia.com is worth a look, Wikipedia with a map.

Joel

Love him or loathe him, Joel Spolsky makes software-development-sense. I wish more people would read things like Picking a Ship Date or Set your Priorities. I'm sure Joel is a pragmatic guy, and though I have no idea if he chows on his own dogfood, I find that I sit here and nod and go "uh-huh" when I read him. He's right on.

Software needs to get done. It has to do things that are critical to the purpose, and it should do things that are helpful. It probably should not try to do much else unless it never needs to ship. And make sure it's what the people want—if that's possible. Amen, bruh-thuh.

Rant: Process Schmocess

In the art of software development with teams larger than one, a process for repeating results is about people. It's about getting them to cooperate and produce something great. That's really it.

I hear groups talk about processes and "resources" (meaning people) and action items and critical paths and all this stuff, and they're full of crap. Their eyes are not on the ball. Management of the process has become the game.

"A perfection of means, and confusion of aims, seems to be our main problem." -- Albert Einstein.

Groups get together and do things in order to produce software. It has to be useful. It's the result of solving a problem, sometimes a whole bunch of problems. If you have an elaborate "process" and spend all your time in that realm, you are possibly probably losing sight of the goal -- great software.

A small group that cranks out great software (meaning it's actually used, it sells, it's profitable, innovative, loved—whatever the criteria for "great" are) and has no process has a good process. If you're a project manager on a team of, say, five people, there is a chance you already have too much "process" smothering your team.

I used to work with a project manager who was the epitome of ineffective. He would try to explain to us something, but it sounded like, "Yeah, we, um, need to review these milestones so we can firm up our deliverables and line up resources so that we can review this with the client at the weekly status meeting and satisfy the action items from last time, too. Alright, see ya." I'd turn to my coworker and ask if he knew what we were supposed to do. "Nope." Me neither.

How about, "Grab Chris, and the two of you get that piece working well enough for us to review it WEDNESDAY A.M. If you have any problems, let me know TUESDAY a.m. and we'll figure out what to do. The client wants an update on THURSDAY. Capiche?"

IT Conversations

This site is a great place to get webcasts or podcasts (or what you will call them) to learn something on your long commute. Download some of these to your music player, start with the highest rated ones. Good stuff.

AJAX is the Word

I'm late to this. AJAX (courtesy of Microsoft, and see those guys at Adaptive Path) might be the thing that finally kills off desktop applications once and for all. The time we spend building setup programs, planning updates that don't do unplanned carnage, and duplicating things when we need both a Windows and web app is astounding.

It's interesting to see how Microsoft, the inventor of XmlHttpRequest, made this possible and then left it out there for others to run with. Now, because of the bewildering flavors of and platforms for AJAX—that is, a lack of a standardized approach—Microsoft may yet wrest control of this from the masses with ASP.NET 2.0 and Atlas. And criticism like this is going to help Microsoft take some of these people by surprise, because they don't get what they think they get. Again.

We can dink with Javascript calls to the server and sew together script.aculo.us and AJAX.NET or DOJO or, man, you name your cobbled together toolset. But this is like version 0.53871 of Web 2.0. We're soon going to look back on this as we do on Windows API programming. A standard way of coding this on the server side is needed. Maybe Microsoft will have the answer, but I shudder to think of how horrid the Javascript generated by Atlas is going to be.

A Good Test

Need a good test for your database application? Take your database server offline. While it's off, write some unit tests and then see how your application is doing. There are a lot of things you may not have realized but thought were OK. For example, does it really need to throw an exception? Does your application's last line of defense (e.g. OnThreadException in .NET) really need to kick in to handle these problems? Shouldn't your program let people work disconnected anyway? Of course I'm raising this issue because our database server is down right now :)

Test before you Guess

Test First, Test Driven Development, TDD, et. al. that represent this now not so new, agile way of developing software... we haven’t jumped into it yet. There is a hurdle and much has been said about this barrier. It can be a hard sell if your audience isn't ready to hear it.

Really, how do you make the case to the people writing the paychecks and putting their necks on the project profitability line that this isn’t some techie geek indulgence? Well:

• Look, it’s a lot of effort up front, and we would rather be writing code and smoking with the time saved not doing it (up front, that is), rather than devising, cataloging, and coding these tests and associated harnesses and refactoring classes into testable units.


• When you suits want to get a handle on the state of the project, or its quality (i.e., do we have a handle on WHEN it’s going to be FINISHED and ACCEPTED), we can almost tell you.


• When (not IF) a change request is accepted and implemented, re-running the tests will tell us if it's broken the rest of the system, without guessing or losing sleep.

The rejection of the myth that we go from requirements-> design-> implementation-> testing-> delivery, in exactly that sequence, is the difference between being effective and failing. TDD sets up your processes to cope with this. Yes, after two weeks using TDD, you may appear way behind, but once the software is feature complete, you won’t be called to the carpet as much for blowing estimates, requirements, QA time, and client agita. That's time well spent, and saved.

The Network is...

Not long ago there was publicity about the computer, the network, and a slick way to glue all this together seamlessly. "The network is the computer" was the mantra, and Java was going to enable our toasters to talk to our iceboxes and stuff like that. Well, this kind of infrastructure, which is dependent on fast and reliable bandwidth, is slowly becoming real, and the snapshot of where we are now shows some value.

For example, storage. I need to store stuff and get to it from anywhere, when I want. Email, passwords, financial records, my favorite bookmarks, whatever. Some of this works pretty well.

But it's chaos.

My email address is... let me think, because I have at least ten of them available to me, and three or four that I use for various things. One for work, one for friends, one for my son's soccer stuff, one to back up my files, one for spammers.

I store things I need at... hmmm, have to catalog all those places where I have megabytes and in a couple cases gigabytes of storage available to me, using ftp, http, vpn, or even CD burner, usb flash drive, or "mp3" hard-disk player.

My latest thoughts are collected in... a notebook, my blog, random documents on hard drives, emails.

No wonder I'm confused.

We are all still learning how to do this. It's a point in the history of our connected world that will be seen as an amusing transition to something much better down the road. We're experimenting, and we're learning and making it better every day. There isn't going to be an end point, but you can fix your own at any time. Just stop learning and trying new things, settle on that set of technologies you're comfortable with, plant your feet and put your hands on your hips and exhale. Frown at how this all seems to be spinning out of control and leaving you bewildered. Good thing the rest of us aren't doing that...

A Friend's Passing

An old friend with whom I lost touch long ago passed away on Sunday. He was 39, taken by a brain tumor. I can't travel to the funeral tomorrow, but I wanted to let his family know I remember him, so I signed the funeral home guestbook online:

My memories of him are mostly from our childhood days in Martinsville, and they are happy memories. He helped me learn how to do things like ride a motorcycle (and I think of him every time I ride mine), laugh like it was all that mattered, and have the courage to face things I’d rather back away from. I lost touch with him years ago, but I am glad to have known him. My thoughts and prayers are with him and all of you.

Life, I'm reminded yet again (and I really didn't need to be, honest), is way, way too short and not predictable.

Rant: Direcway

The city or the country? Broadband web access or something else? I weighed these choices before I moved to the boonies. Satellite internet access is the only choice aside from dial-up. It’s a big step down. It’s a big letdown. Fair access policy (FAP) and bandwidth throttling, no VPN, a system that has its own locked-down NAT and DHCP, no newsgroups… what more can you not want?

I found a nifty utility to monitor bandwidth used before the FAP kicks in, but since it costs $25, I hesitate to endorse it in any way. I’ve already spent enough just to get mediocre internet access: $500 for the equipment and installation, a $60 monthly fee; now I have to pay more just to manage this service?

Almost make me want to go back to civilization. Almost.

Software Requirements -- Communication

Reams have been written, but before you jump into it again, remember three critical things:

1. Define how your team will communicate first.
2. Communicate clearly, concisely, and constantly.
3. Be conversant in the problem domain, and use terms precisely.
   

No matter how you slice methodologies and approaches to the discovery process, poor communication will kill you.

A New Post

All done.