I've been looking through the wikipedia page of software development methods for the last 3 hours, trying to figure out how to maximize my production. But I figured something out- I don't want a software development method.
The advantages of a well implemented SDM are clear. Work is done faster, better, and more efficiently while clients and managers have clear and accurate projections about how the project is going. And I certainly want those things, no question.
The conclusion I've come to, however, is that Scrum, Agile, OOD, XP, RAD and the like are all the same. That's not true, but it's true enough from my seat now. I went searching for how the guys on Silicon Valley organize their efforts, but not because that organization would work best for me or make me better at my job. I went looking for a guide because I wanted the certainty Jared has in that scene. I want to approach people technically superior to myself, show them something they don't like, and have it make a better work environment. Jared is normally so timid- even when he's asking for permission to teach this thing that is going to multiply their output. But as soon as he gets the okay, he's reasonably confident. And for Jared, a man whose real name is Donald but never felt like correcting his boss, reasonably confident is very, very confident.
That's what I like most about his character. He is timid, polite, and (perhaps to a fault) does not want to change anyone's mind or will. That doesn't stop him from asking permission, though. He's most comfortable when roles are clearly established; You:CEO, Me:Trainer, Them:Employees. He says as much later- "Being around angry people relaxes me because I know where I stand.". He prefers the order established by being yelled at than the ambiguity of silence.
This is handy, because Jared is good at establishing order. He knows what to ask for and when to ask it. As soon as he has permission to fix something, it gets fixed, and the company is better for it. This is what I want. Not that fix, but knowing what fix to implement. I want Jared's super power of knowing where to go from wherever you are.
I've been told from many people that I have that, and I admit that I'm decent at knowing what to do in a day or in a fight. It's not hard to review my collection of approaches to a situation and predict their outcomes. I don't value that- probably as a side effect of having it. The fact that I can walk into a room full strangers and give a presentation I've never studied before doesn't seem worthwhile. What would be, however, is knowing what to do a week or year or decade in advance. It seems like no one has that- that there's no crystal ball to give you certainty. But on the other hand, I think Jared would be able to do it if you pushed him.
So, to know what to do a year from now, I think it'd be best to scale up the way I know what to do in a conversation. That takes experimentation with models and the ability to predict their outcome by experience an extensive measurements. That's as abstract as I can get it. The differences are the models and measures. Normally I focus on eye contact, body language, and vocal meter. The models are all the ones they teach you in school- rhetorical questions, alliteration, varying sentence length- plus a few they don't teach, like setting traps- If you make an uncomfortable silence with eye contact, the other person will try to say something to fill the air. Before they do, they'll take an extended breath in. Use this cue to interrupt them before they start. It's really effective.
Anyway, how do I measure a model I don't fully understand to predict an outcome I haven't well defined and have no experience with? All I have to go on is the combined experience of others. So what follows is a list of models used in most of the SDMs I found.
- Test everything and test often
- Make sure tests actually reflect a measure of success (involve the client!)
- Divide the project into sections that lend well to review and feel short
- Don't get technical with planning- your client can't draw the entity relation diagram you need. Ask them to write down a user story instead.
- You can only test something that exists
- The smallest division should reflect how code is written. If you sit down to write it and it's done when you get up, make sure being 'done' can happen before you lose quality
Confidence comes not from knowing the right ways to implement these models, but knowing that you can implement any number of models and understand how each model takes you closer to what you want.
