Posts Tagged projects

What we believe about software development

I came across an excellent (and old) online talk by Greg Wilson on the net today, covering what we believe about software development. It’s a good talk about how little science we use in deciding and reviewing how we plan software, and highlights how many bad or guesstimate numbers computer scientists and engineers throw around when talking about their profession. Watch the video.

The best developers are 28x more effective than the worst

Along with the bad statistics of it, it’s not backed by good data. The studies were long ago with small sample sets, they really don’t apply to modern conditions. Common sense? Not especially. Also, there is the statistical problem of *ever* comparing the best to the worst. It’s a useless measure since ‘worst’ could be someone taught to code an hour ago. Comparing against mean/median/mode is probably a lot smarter.

SCRUM and Sprints keep software from being late

Another good point. As far as I’m concerned, working in a sprint system is what got MakerWare out the door on such a great tight schedule. Iterative design and culling features, as well as allowing for error and error correction during the process. But the plural of anecdotes isn’t data, the plural of anecdotes is rumors. Is there really smarter planning going on? Smarter throwing away features? What is the actual process that makes SCRUM seem or be, better than planning up front?

Until I watched the video, I had not recognized how many software process decisions we as a culture made by anecdote based suggestions, or convinced over beer discussions. If you have time, watch the talk, or add his blog to your RSS reader.

Tags: , , ,

Information Flow rules of thumb

I’ve been thinking a lot about communication and teamwork lately, and reading up a bit on the topic. I think it’s a good analogy to model the movement of ideas on liquid flow. I think a lot of things from Fluid Dynamics can model how ideas pass between people, and how information is passed around. In that vein, I’ve been thinking about Information Viscosity. IE, how well an idea flows from one person to others. And in a working environment, that flow of ideas is essential to progress.

Kristof Kovacs has a great 3 item ‘Ground Rules’ of communication, which is a lot of how I behave. I am going +to adopt it, with a few modifications:

  • Ask: If a task is unclear, if you need information, take 15 to try it on your own. Then ask for help. Doin+g nothing because you don’t know what is right is a waste of your time. If no one has an answer for you, the+n go ahead and keep trying, you’ll be the first to figure it out.
  • Debrief: It’s not done until it’s reported done: A check box, a tick mark, or a one sentence email after testing has happened is part of the process. Things aren’t done until the people needing that tool/project/part+ know that it is available to them.
  • Warn: If something is going wrong, and/or deadlines are going to be missed, you need to warn the people depending on your. Whether that is missing rent to your landlord, or a unexpected problem on a project at work,+ as soon is it’s clear a problem or failure is in progress,
    • I think that is a great set of rules, not only for working on a team in a profit or nonprofit project, but for life in general. They are a good set of guidelines for letting information flow to those that need it about important topics/plans.

      Tags: , ,

Gitmarks

Just a quick note, I found a great project ‘gitmarks‘ through hypatia I’m testing it now, and I think I’ll throw some hours against it.

Tags: , ,

Declined (now with free advice!)

google-street-view-carI recently had the unfortunate pleasure of declining a consulting job with a short “I think your technical plan is invalid” email. Well, it wasn’t that short. I spent 2 hours and 3-4 pages explaining what was problematic, and why the other consultants were unlikely to meet their goals or deadlines (even if they coded every line perfect from the start). The startup idea is/was a good one, and the business plan was decent. But their technical plan was flawed from the git go.

Reading their technical plan make me sputter and say it’s just a bad idea. That reaction is usually caused when my accumulated experiences are informing my opinion, and not rational planning or education. So it was interesting to me to sit down, and try to really understand my gut instinct. So the first thing I did after breathing into a brown paper bag was try to dissect why I have such a strong reaction and what the sane and logical reasons for it.

Read the rest of this entry »

Tags: , ,

Forking is a Good™

linux_fork_miniAfter my talk at PACS a few weeks back, I’ve heard a lot back from people that went to the talk, and (surprisingly) people that read the slides. So much so, I feel the need to post to explain the situation.

To explain when a geek/hacker talks about forking (nerds, go ahead skip ahead to the next paragraph) they are talking about a project splitting apart, and splintering into different projects or groups. The original term comes from Unix/Linux when a process started a 2nd thread. The command to split a running program into 2 copies of itself is literally fork(). Of course, geeks remapped the term onto the situation where development of a project splits. Forking (friendly and unfriendly) is common in software libre projects, and is in the GPL(software license) much the way freedom of speech is in the US Constitution. So you know know forking, and we can move on.

The “Forking is Good” topic has come up in every conversation about the talk I’ve had. It goes something like this:

Friend: …, but the one thing that stood out was your point that ‘forking is a good idea’
Me: But seriously? Wow, I thought that was a common idea.
Friend: No, it makes a lot of sense now. Just .
Me: Oh? Oh. Oh! Now I understand where you are coming from…

I’ve had good and bad forking experiences in forking. I’ve had projects ripped out from under me, as well as friendly cooperative forks, where I am better friends with other developers after the fork. The emotional and intellectual experience of the actual fork often overshadows the quality of pre and post fork projects. That is to say, in people’s opinion the *act* of forking overshadows the *outcome* of a fork. The same way Wisdom tooth removal can overshadow how much better life is afterwords.
Read the rest of this entry »

Tags: , , , , ,