Posted by
Pete McBreen
02 Dec 2006 at 07:29
Saw a good interview of Bjarne Stroustrup recently, including a wonderful soundbite There are just two kinds of languages: the ones everybody complains about and the ones nobody uses.
Bjarne made a great understaement the average Bell Labs programmer was significantly more able than most people’s notion of an “average programmer.” Well that could explain why C++ is expert friendly.
But on that point Bjarne is clear that C++ has indeed become too “expert friendly” at a time where the degree of effective formal education of the average software developer has declined. However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts.
I disagree that more formal education is needed, but we do need to develop more expertise in software development. Personally I have used C++ a lot in the past and was always impressed by the systems that we built using it.
Posted by
Pete McBreen
30 Nov 2006 at 10:47
Brian Marick has finally finished his scripting for testers book now called Everyday Scripting in Ruby. A part of the Pragmatic Bookshelf the book should be a great introduction to the art of scripting tasks to avoid drudgery ;-)
Posted by
Pete McBreen
23 Nov 2006 at 10:45
It is interesting to see that there are starting to be articles critical of SOX. Yes, there were issues to be addressed, but putting a massive layer of beaurocracy on top of already stressed corporations was possibly not the best option.
Posted by
Pete McBreen
18 Nov 2006 at 10:39
There are no shortcuts to becoming a better developer as Uncle Bob talks about in Wading Through Code. Like it or not, becoming a good developer requires a lot of work.
Posted by
Pete McBreen
12 Oct 2006 at 11:50
Brian Marick shares his thoughts about the value of clean code. He supports the idea that the Agile approches require a lot of discipline Agile depends critically on programmers keeping the code clean.
Posted by
Pete McBreen
10 Oct 2006 at 11:51
Steve Yegge has some good questions about how good is Agile development and how do we know for sure about how good it is. He sees quite a lot of religion in the Agile approaches, something I noticed a lot of while writing Questioning Extreme Programming.
To date we have not done any really good experiments to validate whether the claims of the Agile approaches are credible, sure we have lots of anecdotes, but no evidence either way.
Posted by
Pete McBreen
09 Oct 2006 at 12:48
Bruce Schneier poinmted to an interesting failure mode for ATMs. Given that the ATM is a case study in the Use Case Course this is one failure mode we did not consider.
- The man then punched a series of numbers on the machine’s keypad, breaking the security code. The ATM was programmed to disburse $20 bills. The man reprogrammed the machine so it recorded each $20 bill as a $5 debit to his account.
It seems thatthere is a default password to allow the installers to program the machines.
I thought by now we would have learned NOT to have default passwords on systems.
Posted by
Pete McBreen
08 Oct 2006 at 11:55
Over on Coding Horror, Jeff Atwood asked Is Software Development Like Manufacturing?
Posted by
Pete McBreen
07 Oct 2006 at 09:05
A great article by Kathy Sierra about how easy corporations of all sizes focus on internal stuff and forget to make sure that their users are getting great software.
Posted by
Pete McBreen
05 Oct 2006 at 13:13
This was prompted by a comment from Dave Rogers, reminding me that I have been away from writing for too long. After reading he article I was prompted to think about the circumstances under which someone who is recognized as a leader in the field of software development could change their mind about something…
The way IT is set up, there is a real penalty for realizing that you want to change, but at the same time the technology is changing so fast that we all need to change. Hence the leading Java gurus are unlikely to become the leading .Nyet gurus, even though for most practical putposes Java is indistinguishable from .Nyet.
Posted by
Pete McBreen
23 Aug 2006 at 14:32
Not sure where I read it, but in one of the many blogs about the 25th anniversary of the IBM PC, someone was talking about not seeing computer operators any more.
Kind of puzzling that, because although most sites no longer have anyone with a title of Computer Operator, there sure are a lot of System Administrators around. The daily tasks they might be doing are subtly different, but the basic goal of what the System Administrators do is basically the same as that of the Computer Operators, keep the machines running, back up the data and do system upgrades.
Requirements can look different when presented under a different role name, but the only difference may be in the details of the technology. At the summary level the goals are the same, we still need someone to look after the machines so the real users can get on with handling their day jobs.
Posted by
Pete McBreen
12 Aug 2006 at 04:25
Over the past 30+ years, the way we investigate, analyze, capture and
communicate requirements has changed at a much slower rate than the way we do the rest of software development. Use cases shifted things a bit and the more recent user stories have had some impact, but while the productivity of design and development activities have improved dramatically over the last 30 years, comparatively, requirements activities are still stuck in the quill pen era.
Improving requirements activities means adopting different ideas about what it means to investigate requirements, to reappraise what it means to communicate requirements and to fundamentally rethink the role of requirements in software development projects.
Being aware of the distinction between explicit and implicit constraints helps, but it is not enough.
- Some requirements can just be documented, they are well known
and understood (the explicit constraints)
- Some requirements emerge as part of conversations (the implicit constraints)
- Some requirements do not really exit yet, they have to be invented
Posted by
Pete McBreen
11 Aug 2006 at 15:31
An article of faith in the software engineering community is that it is possible to document the requirements for a system before it is built.
I beg to differ. Sure, we can capture some of the obvious transactions that a system needs to support, and Use Cases are a great way of capturing this aspect of requirements. But, by definition, implicit constraints only really surface when someone is surprised by the difference between what they expected and what they got.
It is hard work to probe and question early on in a project to attempt to discover the implicit constraints, and my experience is that most projects don’t do very well at this. All seem to suffer from a nasty surprise or two just when everyone (except possibly the quality assurance people) is starting to think that the project is starting to really look like it is going to deliver a good system this time.
Posted by
Pete McBreen
08 Aug 2006 at 15:00
One way I used to think about requirements was by making a distinction between facts imposed on the developers and design choices that were left to the developers. The facts were a way of thinking about the requirements.
Since then I have started to think more in terms of Constraints and Design Choices, mainly because the word constraints allows for more nuanced thought.
- Constraints are negotiable
- Some constraints are explicit
- Some constraints are implicit - and lots of problems arise from these culturally known items
- Constraints change over time, sometimes being relaxed, other times firming up
- New information can totally blow away existing constraints while imposing others
The implicit side of constraints are the most interesting for me currently, since these are the ones that are never written down. Not because people do not take the time to write them down, but because it never occurs to anyone that they need to be written down - after all it is just the way we do things around here. Since everyone know it, there is no thought that there is anything to write down.
The problem shows up however when someone form outside the culture gets involved with the development team. Now the outsider gets a whole lot of surprises as these implicit constraints get surfaced as disconnects and contradictions.
Posted by
Pete McBreen
04 Aug 2006 at 14:35
Why do technologies and programming languages catch on? My guess is that I make the effort to learn those technologies that give me reasonably immediate gratification.
Yes, I can do delayed gratification, and I’m not all that into instant gratification, but I notice that the tools and technologies I know best are those that enabled me to do somethin useful fairly quickly. Interestingly that set includes 8080 assembler because it enabled me to do something interetsing on a MPM machine when I was starting out as a paid software developer back in 1983
Posted by
Pete McBreen
20 Jul 2006 at 02:15
Republished What to do when the estimate is wrong article on this site.
Posted by
Pete McBreen
19 Jul 2006 at 09:46
This is a follow up to my Software Craftsmanship and Questioning XP books, further exploring the way that we develop software.
Technology is never the issue
Ok I did make the case that Java could be but even it has stabilized enough that as a technology it is unlikely to be the cause of a project failure. The real cause of Java projects failing is the way that the team used the various parts of the Java platform.
Similarly for the .Net platform, it would be hard to pin a project failure of the .Net technology. How people have mis-used it could account for a lot of projects however.
So what are the issues?
I don’t know, but I’suspect it is the way we think about and talk about software.
Hence we need to improve our own wetware
Admittedly wetware can have some visceral images associated with it, but maybe that is an advantage in engaging our emotions with the issues.
