Don't be the builder, be the user

I was helping out today with a project my Dad is having done at a business. In the building, there is a need for more workspace and so it needs to be built. I was amazed at the staggering similarity of the conversation between my Dad and the builder and software design conversation. I was on site to be an extra set of hands for construction, meaning my viewpoint was meaningless.

The construction required two free standing walls, and a overhead "rail" to contain electrical down into the units that will be installed against the walls. The specifics of the construction and its are left out intentionally. To conceptualize, the objective is more workspace.

There was no plan, no paper, no agreement. Nothing except conversation, movement of existing workspace to demonstrate possibilities and measurements that resulted in pencil writings on raw material. Once the existing physical objects were in place to demonstrate the projected future space, measurements taken and verbal agreement, the overall planning was done. The builder understood what my Dad wanted, and we were off to buy material and begin construction.

After reading "Doing It Wrong", I was somewhat amazed how such a major change to the environment was made so quickly. A software project would have taken weeks of conversation between technical departments to agree on positioning, material, measurements, etc.

And so I thought, what made this conversation successful? My Dad didn't care about material, measurements, and a majority of the implementation details. The trust existed that the builder would make those decisions himself. My Dad wasn't trying to be the builder.

I think this is a major difference in software / technical planning. Many people seek to be the builder when they have no place wearing those shoes. It's either out of their skill set or job assignment. The perception of technical understanding equaling intelligence is completely out of whack. So many details are exposed unnecessarily, and the conversation to explain those details derails the initial objective so much, that the skillful developer that just knows how to do it, is lost. They are forced down the road of writing specs and explaining themselves to people that don't deserve the explanation. Let alone the boring and uninteresting process of formalizing a design that will entirely change two minutes down the implementation path because one little aspect wasn't considered.

My advice to people who want something out of software is to step beating up the details. The software engineer will figure it out. Don't try to be the builder, be the user. Your product will finish a lot quicker if you push the use over the build.

public String toString()

I was writing a simply toString() implementation today to easy my view of an object when debugging. After I was done, I thought, why isn't this standard in all objects?


public String toString(){
try{
Method[] methods = this.getClass().getMethods();
Object[] arguments = {};
for(int x=0;x<methods.length;x++){
Method nextMethod = methods[x];
if(nextMethod.getName().startsWith("get")){
Object value = nextMethod.invoke(this,arguments);
buffer.append(nextMethod.getName());
buffer.append("=");
buffer.append(value);
buffer.append("|");
}
}
} catch (Exception e) {
// do something
}

return buffer.toString();
}


The basic point is to simply show the values on the object via the getters. Seems to be useful.

Make Software Slow Switch

I think the conversation of what sucks verses making something great is always interesting. Developers are always quick to judge existing work rating it as poor when they didn't write it. And of course, the judging developer can always do it better. In my opinion, its easy to break something down and discover whats wrong verses :

1. Putting it together right the first time and/or
   
2. Fixing whats broken without breaking something else.

If you are priding yourself with a discovery of an issue, I wouldn't brag too much. You didn't create the issue, and you haven't fixed it yet.

As much as I hate these conversation, I am much interested in the reverse. Can you intentionally make software worst? I think this is much harder problem for developers because:

1. We think mostly positive (I hope, I am not speaking to viruses or malicious software)
2. We would work so hard for the worst of the worst it might never work and
3. You have to make something good or great first and then understand how to ruin it.

Getting to the good or great first.... well good luck, it takes time. Great can be rated in terms of the original judging, if other developers think the software is good or great, you are on the right path. Hopefully you have test cases to indicate your success. Now, your test cases must succeed still, but with poor performance (assuming performance was not in your original test case) or quality. The design goal is to keep your existing great software, and to inject a switch to make it run poorly. Having the base test cases simply fail would not be the success here as the software must function.

I guess there is no point here, simply to invoke thought mainly. Developing with awareness of something that will get you to done, but a quality rating as well of satisfaction is very different. Test cases get you to done, but does quality fit into test cases? Should performance be a test case?