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.
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.
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.
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.
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.
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.
16 May 2008 at 20:04
A nice article about the problems with UML, including the issue that it has an 800 page specification. In all 13 points are listed, some of which may be the reason that UML is not used much these days.
UML can still be useful for sketching out ideas on a whiteboard, but the way that most CASE tools operate it is hard to just sketch out ideas.
05 May 2008 at 20:03
One to ponder: We don’t know how to program
File this under the same category as Jack Reeves The source code is the design - Yes I know that is not quite the title for the article, but that has always been the way I think about this article. The actual title is “What Is Software Design?”
Paul Johnson points out that there is no real process for software development because most of it is design and nobody really has a process for that, since it occurs in the heads of the designers. I would also add that it also occurs in the conversations between designers and other people, because sometimes it is external ideas that spark great designs.
Overall though there is no process, and just like other design disciplines, software development is best learned through apprenticeship to a great designer.
01 Mar 2008 at 19:56
A great talk by Alan Cooper on modern Craftsmanship.
A great video called An Insurgency of Quality - mp4
Beau Smith has a good writeup/transcript. Video used to be at Brightcove.TV but they are no longer hosting the video.
27 Jan 2008 at 19:55
Michael Feathers wrote an article for Beautiful Code called On Loving C.
“C has its quirks, but in retrospect, they are a lot less mysterious than the quirks of many other languages.” Well put, there are many languages out there that are really obtuse, containing many more quirks than C.
21 Jan 2008 at 20:06
Crosstalk has a good article this month on where are the future software engineers. In part the article is the usual rant against the teaching of Java as a first programming language, but it is more nuanced than that.
The authors point out that the mathematical requirements are shrinking, and the students are not really being taught the basics any more. Sure Java is nice and easy to learn but it is not a suitable preparation for working in embedded and real-time systems.
I’m still pondering how this relates to software craftsmanship, since traditionally many craftsmen have either a comp sci or sw eng background.
Article references ACM Computing Curricula 2005 overview report, which is also an interesting read.
27 Oct 2007 at 19:53
“The elementary rules of logic, that extraordinary claims require extraordinary evidence and that what can be asserted without evidence can also be dismissed without evidence.” Christopher Hitchens
“Wishful thinking is one thing, and reality another.” Jalal Talabani
“The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair.” - Douglas Adams (1952 - 2001)
“It’s harder than you might think to squander millions of dollars, but a flawed software development process is a tool well suited to the job.” Alan Cooper The Inmates are running the asylum
23 Jul 2007 at 19:51
I wrote this article for InformIT back in 2002, and someone on Reddit discovered it this week.
“While Java and C# have been receiving all of the publicity of late, a lot of software is still being written in C and C++. Indeed, many traditional languages such as COBOL, FORTRAN, and Ada are still in widespread use. Although I harbor a certain fondness for COBOL, and have written more Java code over the past five years than is probably good for me, I’m finding more and more that I’m drawn back to C and C++.”
“I’m coming back to C and C++ in part because I prefer stable development environments, and because I’ve come to appreciate the power of object-oriented scripting languages, particularly Ruby. Ruby is evolving rapidly, but then I don’t try to write really long-lived code in a scripting language. I use scripting languages for code that I want to be able to write rapidly, to test ideas or to implement some valuable functionality quickly.”
Java is not in the news as much, but Ruby is growing in popularity thanks to Rails.
Overall I still stand by what I wrote back then,
“What this means for developers is that the future of C and C++ is secure for a long time. Other languages might have nicer development environments and be marginally more productive, but for the core business logic of mission-critical applications I still prefer C and C++. I’d choose other languages for the rapidly evolving parts of the application such as the user interface and the web front-end, but for the core of the application I have nothing but praise for C and C++.”
I wonder how many Rails apps out there have some key bit of functionality coded in C while Ruby handles the rest of the application?
18 Jul 2007 at 20:07
Nice article on Idiomatic ruby.
04 Jul 2007 at 19:50
In Certification? Bring It On! Raganwald seems to think that his recent experiences with people asking about degrees can be alleviated by a new style certification.
Unlike other ideas, all that this type of certification covers in one subject.
The one subject? Testing and Quality Control. That’s right. All I care about is that if you are asked to make bulletproof software, you know how.
Inspired by the mistaken ideas that all that matters in a restaurant is that the chef will not poison you, this misguided attempt at vertification assumes that all that really matters is that “someone can be relied upon to write software that is safe”. Unfortunately, there is the assumption that someone who can pass an exam can deliver.
An unwarrrantied assumption in most cases.
02 Jul 2007 at 19:49
At a time when a developer can be called a “senior architect” with only 5 years experience, what do you call someone with 25 or 35 years experience?
Unfortunately, for the most part we can no longer call them developers, because there are few developers with 25+ years experience. Most have either drifted into other fields, been moved into management or are now independent consultants. It is rare for a developer to be able to keep improving their craft skills for 25 years because they get sidetracked into other things.
Other fields of endevour do not have this problem, so I suspect that the economic incentives in software development are skewed such that it makes little sense to get really good at being a developer.
28 Jun 2007 at 19:48
Eric Wise wants to become known as a software craftsman. His view is that craftsmen attempt to select tools, patterns, and practices and with them craft beautiful, working software.
His post has interesting parallels to the book Software Crafstmanship.
21 Jun 2007 at 19:47
Some thoughts on finding good developers to work on your projects.
To attract good developers you have to let them know what kind of application you are building, because there are two important questions that developers need to be answered about any development job - will this build my skills and reputation, and is this the kind of application I enjoy creating.
If you just list the technology in the project listing it is a negative because it implies you just want a coder to follow directions, so immediately you go to the bottom of the list of possible clients.
So to attract good developers, sell them on your idea of what you want to build. Specify the technology if you must, but that will cut down the number of people who will be interested in doing the work. You will also have to find some way of signaling that you have the budget to afford the type of people you want. It would also help if you could let people know the timeline and commitment involved - is it a small part-time task or full time total involvement year long task.
06 Jun 2007 at 19:40
It seems that once again some people are pushing to create a certification program for software developers.
This time they are promoting the idea that prefessionalism requires a certifying body with recognized certifications just like accountants etc. Luckily the author of the article is alert ot the problems of credentialism, so maybe the movement will be stillborn, but we need to stay vigilant to ensure that our craft does not get stuck in teh stone age due to some corporate welfare scam of IT credentials mandating that everyone who wants to work in It needs to know about mainframe JCL.
20 Apr 2007 at 19:45
I never cease to be amazed by project managers who give lip service to the idea that there are some unknowns in their project plan and then give precise estimates for their schedule.
It seems as if intellectually we can see that there are unknowns, but when it comes to our projects we think we are special and we can precisely predict how long our project will take.