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.
My point of view and areas of interest on software, technology, computing, etc.
Sunday, January 10, 2010
Friday, January 8, 2010
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?
The basic point is to simply show the values on the object via the getters. Seems to be useful.
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.
Labels:
Java,
Reflection,
toString
Monday, January 4, 2010
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 :
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:
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?
- Putting it together right the first time and/or
- Fixing whats broken without breaking something else.
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:
- We think mostly positive (I hope, I am not speaking to viruses or malicious software)
- We would work so hard for the worst of the worst it might never work and
- You have to make something good or great first and then understand how to ruin it.
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?
Labels:
Performance,
Quality,
Testing
Subscribe to:
Posts (Atom)