The Argument From Ignorance
Posted by Pete McBreen 22 Sep 2009 at 20:28
Neil Tyson talks about the argument from ignorance
Beautiful quote from Neil - “Optical Illusions are Brain Failures”
Certification just won't go away
Posted by Pete McBreen 22 Sep 2009 at 20:10
I just love this Joe the Developer doesn’t need a certificate from Gojko Adzic
What is really amazing about this particular time is that serious people whom I respect seem to be arguing for certification, with the idea that certification is coming anyway so it’s better if the community gets on board and influences it rather than ignoring it and suffering after. To that I can only say that people do drugs anyway but it’s still not OK for us to sell it to them.
It seems that there is now a move afoot to make Certified Scrum Developers… The World Agile Qualifications Board .. words fail me.
Cooper on Agile
Posted by Pete McBreen 22 Sep 2009 at 20:04
“I’ve long been an advocate of such technological-craftsman-self-determination. It’s just that I advocated it via the “interaction design†point of view. ”
Kent Beck's blog has some great quotes
Posted by Pete McBreen 20 Sep 2009 at 09:41
Some of it is priceless.
… hordes of junior programmers with just enough adult supervision to prevent disaster.
Software design must resolve a set of mutually contradictory requirements
Nice to see that Kent is thinking beyond XP now Incremental design as described in XP takes a firm stance on such situations: eliminate the duplication or the excess complexity as soon as you see it. The responsive designer, however, takes a more nuanced approach.
Nice observation from Scalzi
Posted by Pete McBreen 20 Sep 2009 at 09:02
A general observation from Scalzi,
The Internet does seem to be full of people whose knowledge of complex concepts appears limited to a dictionary definition.
Decentralizing social media
Posted by Pete McBreen 15 Sep 2009 at 18:28
Decentralizing social media s likely to become a hot topic.
Dave WIner has created RssCloud to enable more or less real time RSS updates and notifications, helping to decentralize the notification system. Twitter was an interesting model for a while, but it has demonstrated that it does not scale to a real flash mob. Sure it works well for large traffic volumes, but when there is a massive spike in traffic the centralized model is always going to be in danger of slowing down.
At some level high traffic is indistinguishable from a denial of service attack, sure the traffic is wanted, but if the servers cannot handle it, then the system exhibits the same behaviors that it would under a real denial of service attack - no new traffic gets through in a timely manner.
Defending Software Craftsmanship
Posted by Pete McBreen 12 Sep 2009 at 20:23
Saw this a while back but forgot to link to it.
In Defense Of The Software Craftsmanship Concept by Alan Skorkin
What about simply writing clean, nice code and doing it quickly and well. While I would love to say that anyone can do it no matter how ‘old’ they are, I would be lying if I did. Any developer who has ever looked at code they themselves wrote 1, 2 or 3 years ago will tell you that this is one skill that you can hone and improve until the day you, errr — become a manager (don’t bite my head off, i am only kidding :)). The point is, having a skill that you can continue to improve for as long as you’re able is the very definition of craftsmanship.
Other than the subtle jibe at managers, a nice summary of software craftsmanship.
Masterpiece Engineering
Posted by Pete McBreen 05 Sep 2009 at 16:44
Stumbled across this paper from the 1969 NATO Software Engineering conference that indicates that even back then someone was thinking that maybe engineering was not the right metaphor for software development
Unlike the first conference, at which it was fully accepted that the term software engineering expressed a need rather than a reality, in Rome there was already a slight tendency to talk as if the subject already existed. And it became clear during the conference that the organizers had a hidden agenda, namely that of persuading NATO to fund the setting up of an International Software Engineering Institute. However things did not go according to their plan. The discussion sessions which were meant to provide evidence of strong and extensive support for this proposal were instead marked by considerable scepticism, and led one of the participants, Tom Simpson of IBM, to write a splendid short satire on ”Masterpiece Engineering”. –Brian Randell
Since then we have endured 40 years of people pushing the software engineering ideas on us, and in spite of all that projects still have major stresses.
Lecturing Birds on Flying
Posted by Pete McBreen 03 Sep 2009 at 19:40
Lecturing Birds on Flying is another take on Nassim Taleb’s Black Swan idea, and Pablo Triana does a good job of explaining that a lot of what was supposedly solid theory around financial modeling, is actually not applicable in the real world.
It turns out that most models make the assumption that the probabilities that apply in markets are normally distributed (where anything beyond a three sigma event should be exceedingly rare), is incorrect and that the probability distribution has very “fat tails”, where a twenty-five sigma event is not unheard of. This work complements Nassim’s black swan book by restating the ideas in a slightly different way and by being written after another event that demonstrates that the markets do not have normally distributed probabilities.
The applicability to software craftsmanship stands out for me in the way that the models try to ignore the effect that individuals have on the market. The assumption is made that the actions of individuals are all independent, when it is blindingly obvious that this is not the case. Yes, the assumptions might work if the market was made up of lots of small players, but that is not the case. The markets only have a few players of any significance, the trades of any of these make the markets move, the small players make the random day to day noise, but the big players are what cause the problems - the too big to fail kind of problems.
Software Engineering is too big to fail
To get a good software disaster, you need the big ideas from software engineering that can influence lots of people to make similar mistakes on a project. The average level of software development is abysmal, most projects only succeed to the extent that they have one or two talented or experienced developers who manage to overcome the overall lure of failure.
Software projects should be built around the outliers that happen to be talented or experienced enough to succeed, but even then the sponsors should only bet as much as they can afford to lose. Nobody knows how to make massive projects successful - other than throwing money at it until it is politically acceptable to call the result successful.
The issues in software are different than in finance, but in both cases the underlying model of how the field works is incorrect, and the consequences of this mismatch between model and reality are what causes things to crash and burn.
Which is better, an untested theory or not knowing?
Posted by Pete McBreen 02 Sep 2009 at 18:41
Sometimes it seems that it is very hard to admit to not knowing something. It is as if having a convincing tale to tell about something is more important than actually being correct.
Explanations are listened to
Unfortunately this is true even when the explanations are based on pure guesswork, and potentially have no grounding in reality.
Nobody quotes the people who do not know
Most media are interested in the quick soundbite that explains an event, they are not interested in anyone who says that the causes are complex, interrelated and not amenable to a quick fix.
Maybe the best methodology is None of the Above
Most of the methodologies I have seen appear to be just guesses about what might work, but they are presented as it they are the one true solution to all our software development problems. Some methodologies allow for experimentation and as such are partially admitting that they do not know for sure, but it is a rare event for practitioners of any methodology to admit that maybe alternate approaches may be more suitable for a project.
While not advocating a roll your own methodology approach, I do advocate admitting that we do not know what really works for software development projects. Sure we know a few ways to Crash and burn projects, but that is not the same as knowing how to make a project succeed.
Back after a long gap
Posted by Pete McBreen 01 Sep 2009 at 19:51
Finally managed to restore this site after the original hosting site went away.
On the positive side, the backup_blog.rb script that I wrote several years ago proved to work first time with this new version of typo (5.3), so all of the old blog postings are now available again.
Now all I need to do is remember to post to this blog on a regular schedule again.