Developers need watches. Developers are the ones that can't keep secrets :o) It is also pretty hard to beta test a watch in the real world world without going into the real world. At some point you have to go public. Of course there are other reasons, like some issue with production (odd the demo units at event were true demo units), but these other issues are just as likely. Even with build issues, you still need to get the watches that do work out into the world to see what else breaks.
Wednesday, September 10, 2014
Friday, August 29, 2014
Musings of the Sorry State of Developer Accountability
Things I see...
5 minute change takes three days.
Screens developed don't look like screens delivered.
Data developed is only marginally like data specified.
Developers concentrate on code, not understand what they are coding and why.
It all falls down to this: Developers don't take the time to plan, they just code and make things up rather than understand why, create a plan, execute and validate.
Why is this happening? Management... But that's just pointing fingers. Management has not really caused a problem. Yes management wants it right now. The problem is that programmers are fighting for their jobs and feel like they must do everything that management says. There is no give and take. There is no negotiation. Programmers don't think and push or pull to get it right, they just do what management says and the blame customers/mangers for being unreasonable and causing the errors.
This is akin to war crimes. Really. Sorry. I just did what my superior said. I am but a soldier and not responsible for the crimes of my superiors.
Projects fail, applications crash, customers complain, data is corrupted, core capabilities don't exist or are so wrong that they are so poorly executed that they can't even be compared to wrong, let alone close to right.
Nothing can fix this but personal responsibility and pride in your work. Agile, Scrum or any other process is useless. If you can't fight for doing it right, please go home.
5 minute change takes three days.
Screens developed don't look like screens delivered.
Data developed is only marginally like data specified.
Developers concentrate on code, not understand what they are coding and why.
It all falls down to this: Developers don't take the time to plan, they just code and make things up rather than understand why, create a plan, execute and validate.
Why is this happening? Management... But that's just pointing fingers. Management has not really caused a problem. Yes management wants it right now. The problem is that programmers are fighting for their jobs and feel like they must do everything that management says. There is no give and take. There is no negotiation. Programmers don't think and push or pull to get it right, they just do what management says and the blame customers/mangers for being unreasonable and causing the errors.
This is akin to war crimes. Really. Sorry. I just did what my superior said. I am but a soldier and not responsible for the crimes of my superiors.
Projects fail, applications crash, customers complain, data is corrupted, core capabilities don't exist or are so wrong that they are so poorly executed that they can't even be compared to wrong, let alone close to right.
Nothing can fix this but personal responsibility and pride in your work. Agile, Scrum or any other process is useless. If you can't fight for doing it right, please go home.
Wednesday, December 21, 2011
Associative Reality
Aggregation (white diamonds), composition (black diamonds), simple associations, directed associations, and ownership(containers) are steak and potatoes of object oriented structures and our favorite modeling language, UML. I recently worked with a client that used composition for parts of a configuration rather than aggregation which seems logical given the reuse of parts between configurations. This was SysML, but the standard used the common UML concepts and meaning. The customer used composition for configuration relationships because the concept itself was light weight, i.e. the car configuration was a configuration of car, not a true car.
You might say an illusion owns elephant, thus when the illusion dissipates, so does the elephant. Or for you dessert rats, the water in the mirage is gone when the mirage is gone. In a car, the parts are created and destroyed like arms and legs, but when we stop creating a model of car, it ceases to own the responsibility for those parts. Another model of car may be composed of the same radio, but they are not shared nor does deleting one car model destroy the other's parts.
It may be that we are always struggling to pin our hopes and dreams on our ability to control our destiny through these concepts when they are the wrong hopes. Take for instance, directionality of relationship. This is pure software isolation, not system engineering. What if I know your name, but you do not know mine... yet? Is that bidirectional? Does an engine know the transmission it is connected to and vis versa? Yet both have effects on each other via linkage.
Aggregate/composite/owns are software terms and perhaps not as applicable to the real world. It would be interesting if we dug into the haggis of software concepts to find why and where these terms originated. They certainly loose their shine when applied to systems engineering.
Sunday, May 22, 2011
Moon Buggy
Was watching Moon Machines on the Science Channel today. Here is a great quote from Alex Kosmala, Flight Software Developer, MIT Instrumentation Laboratory:
There were no specs. We made it up. And its always amazing to me, why was I allowed to program something that hadn't even been specified, that would be critical in assuring the success of the whole Apollo space program. I couldn't believe it. But, that's the way it was. We made it up as we went along.
Saturday, March 26, 2011
UML helps you prevent your brain from exploding
Yep, UML helps you keep your head. Just take an actor in a use case diagram. Why is it a stick figure? Perhaps because we are not artists. Imagine having to draw whistler's mother everry time we're representing a user. Go ahead, we'll wait for you to imagine how hard this would be.
What about class diagrams? Think about it for a second, based on how hard it is to imagine a couple thousand lines per class of spaghetti (just 100 lines lasagna if you are good programmer). A class diagram symbol is just a symbol. At most we define name, attribute and method signatures. We do this for good reason. To add more detail implies we actually can absorb, understand, and remember the complete program.
The facts are, we are sloppy and lazy. We can't keep more than a few things in our heads at one time. Sure we match patterns, but not thousands of lines of Java at the same time. We think linearly. We also are not savants with photographic memories.
Sorry, no idiot savant here. We need a crutch. That's UML.
Developed by nerds, not artists, UML is a cartoon of symbols, not a detaied 3d representation. UML is ugly and unimaginative. Ugly is good. You don't buy ugly a new car from irrational imaginings of a good time. Ugly is functional.
People complain that UML is confusing. Sure, that's true, but only if you don't understand UML, or objects, or in fact have the ability to abstract life and the world. UML is just a language of symbols. You need to learn to read and write before the alphabet is really useful.
Ok, enough. Go learn. We'll be waiting.
What about class diagrams? Think about it for a second, based on how hard it is to imagine a couple thousand lines per class of spaghetti (just 100 lines lasagna if you are good programmer). A class diagram symbol is just a symbol. At most we define name, attribute and method signatures. We do this for good reason. To add more detail implies we actually can absorb, understand, and remember the complete program.
The facts are, we are sloppy and lazy. We can't keep more than a few things in our heads at one time. Sure we match patterns, but not thousands of lines of Java at the same time. We think linearly. We also are not savants with photographic memories.
Sorry, no idiot savant here. We need a crutch. That's UML.
Developed by nerds, not artists, UML is a cartoon of symbols, not a detaied 3d representation. UML is ugly and unimaginative. Ugly is good. You don't buy ugly a new car from irrational imaginings of a good time. Ugly is functional.
People complain that UML is confusing. Sure, that's true, but only if you don't understand UML, or objects, or in fact have the ability to abstract life and the world. UML is just a language of symbols. You need to learn to read and write before the alphabet is really useful.
Ok, enough. Go learn. We'll be waiting.
Tuesday, March 15, 2011
Proof of Life
Avoid addressing problems, issues, events, or constructs that are not proven to exist in the real world. This is like "proof of life" used in hostage negotiation. Here you should not proceed until there is proof that the need either exists or there is a commitment to existence.
Proof of life or existence of a concept in the real world should be confirmed before allowing a concept to be added to the process or metadata. Simply, there are things we imagine that might exist that do not exist in reality. Imagination and antidotal-based evidence lead us to create scenarios that are not realistic. We need to limit effort based on impossible or rare edge cases.
Dealing with edge cases and error conditions is important. How exceptions are dealt with can be designed so that the effort is applied at the exception, rather than designing expensive infrastructure to solve a problem that may never occur.
We hate failure and that is why we come up with many scenarios that may only be imagined. If something might happen, we believe it actually does happen. The difficulty is proof that will satisfy a critic. The best case is that without proof, we cannot assume it is necessary to address or that we address with a lower level of effort. Those things that have definitive proof have priority.
It is important that our primary modeling tool is UML-based with UPDM, SysML and other standards. These give us all the building blocks and levels of abstraction so that we avoid reinventing the wheel. We also have one place to look for what we have proved to exist and even what does not. Unlike cowboy-agility where we erase the whiteboard on every iteration, we have a history that gets smarter after each iteration. Don't be afraid to document an activity and add metadata to classify it as 'do not implement.'
Address primary use cases and important edge cases, but should not attempt to address those that cannot be proved. There may be guidance for addressing such unknowns and ensure that efforts are reviewed to ensure success.
A good test of "Proof of Life" is a repeatable and complete test. If you can create a test, then it is at least possible to show the exception in practice. This works well for software, but also applies to your development process and any automation and metadata of the process.
Proof of life or existence of a concept in the real world should be confirmed before allowing a concept to be added to the process or metadata. Simply, there are things we imagine that might exist that do not exist in reality. Imagination and antidotal-based evidence lead us to create scenarios that are not realistic. We need to limit effort based on impossible or rare edge cases.
Dealing with edge cases and error conditions is important. How exceptions are dealt with can be designed so that the effort is applied at the exception, rather than designing expensive infrastructure to solve a problem that may never occur.
We hate failure and that is why we come up with many scenarios that may only be imagined. If something might happen, we believe it actually does happen. The difficulty is proof that will satisfy a critic. The best case is that without proof, we cannot assume it is necessary to address or that we address with a lower level of effort. Those things that have definitive proof have priority.
It is important that our primary modeling tool is UML-based with UPDM, SysML and other standards. These give us all the building blocks and levels of abstraction so that we avoid reinventing the wheel. We also have one place to look for what we have proved to exist and even what does not. Unlike cowboy-agility where we erase the whiteboard on every iteration, we have a history that gets smarter after each iteration. Don't be afraid to document an activity and add metadata to classify it as 'do not implement.'
Address primary use cases and important edge cases, but should not attempt to address those that cannot be proved. There may be guidance for addressing such unknowns and ensure that efforts are reviewed to ensure success.
A good test of "Proof of Life" is a repeatable and complete test. If you can create a test, then it is at least possible to show the exception in practice. This works well for software, but also applies to your development process and any automation and metadata of the process.
Thursday, September 2, 2010
Why Software Sucks (more than it should)
Here at Boys Books we were breaking in another software slave (intern). As usual we waxed poetically (actually dirty limericks). We grumbled about the olden days when software did interesting things and worked in expected ways. This is of course a lie. Things are vastly better now, they just suck more.
If we can create a vacuum that never loses suction, why can't we write software that doesn't suck?
We think the real reason is the invention of railroads. One track minds have plagued us as a metaphor ever since the iron giants rolled across the American plains scarring prairie dogs. The common programmer seems to be trapped on the tracks with just one goal at a time in their heads.
Ask a programmer to create an game. They will create a great game, but that's all. What they won't do is make it easy to learn, simple to install, and other useful things like integrate with facebook and worse, won't show up on google. The game will be one dimensional suckyness.
You might say, "My iPad games were easy to install." Well, that's one. But why was the game easy to install? Because Apple installed it, not the programmer. The game might (and few are) be easy to use. Again, the only reason is iPad's touch interface and accelerometers. The same game would require the user to memorize fifty keyboard commands. The programmer is still on one track, but the track is happily going through some scenic parks rather than a toxic waste dump. The same programmer in front of a PC is still writing the same garbage.
What is the solution? Jump the tracks! Toss a few pennies in front of that train and derail it! The pennies are the imperatives that we know as who, what, why, when, and how. Programmers just have the rails of what and how. They need the rest to really get things moving.
But don't stop with the imperatives. We need to also have time, location, emotion, motivation, least surprise, novelty, and a web of connections to all of these concepts and the imperatives.
Why shouldn't the game play differently based on your location? If you play a driving game in Dallas, half the drivers have guns (and use them), and the other half of drivers are moving at ten miles under the speed limit and have Oklahoma license plates. See what just location adds? What about 'when'? Imagine racing at rush hour or through cop infested school zones in the early morning?
NOTE: These ideas and concepts copy write by Daniel Brookshier. All ideas are for sale at a reasonable price.
If we can create a vacuum that never loses suction, why can't we write software that doesn't suck?
We think the real reason is the invention of railroads. One track minds have plagued us as a metaphor ever since the iron giants rolled across the American plains scarring prairie dogs. The common programmer seems to be trapped on the tracks with just one goal at a time in their heads.
Ask a programmer to create an game. They will create a great game, but that's all. What they won't do is make it easy to learn, simple to install, and other useful things like integrate with facebook and worse, won't show up on google. The game will be one dimensional suckyness.
You might say, "My iPad games were easy to install." Well, that's one. But why was the game easy to install? Because Apple installed it, not the programmer. The game might (and few are) be easy to use. Again, the only reason is iPad's touch interface and accelerometers. The same game would require the user to memorize fifty keyboard commands. The programmer is still on one track, but the track is happily going through some scenic parks rather than a toxic waste dump. The same programmer in front of a PC is still writing the same garbage.
What is the solution? Jump the tracks! Toss a few pennies in front of that train and derail it! The pennies are the imperatives that we know as who, what, why, when, and how. Programmers just have the rails of what and how. They need the rest to really get things moving.
But don't stop with the imperatives. We need to also have time, location, emotion, motivation, least surprise, novelty, and a web of connections to all of these concepts and the imperatives.
Why shouldn't the game play differently based on your location? If you play a driving game in Dallas, half the drivers have guns (and use them), and the other half of drivers are moving at ten miles under the speed limit and have Oklahoma license plates. See what just location adds? What about 'when'? Imagine racing at rush hour or through cop infested school zones in the early morning?
NOTE: These ideas and concepts copy write by Daniel Brookshier. All ideas are for sale at a reasonable price.
Subscribe to:
Posts (Atom)