Currently viewing the category:
"Software Engineering"
Results from a survey concerning 400 IT projects:
What were the surprises?
- Most projects that had no schedule were successful
- Requirements are needed for project success, but not necessarily early in the project
- Projects often continue successfully for some time with unclear requirements
- The choice of requirements methodology does not matter; UML was “no help”
Success/Failure Criteria: Some Surprises by Robert L. Glass – developer.*, Developer Dot Star
I find the results interesting. I’m not as surprised by the preceding points as the author (Robert Glass, whose excellent book Software Conflict 2.0 I’m currently reading). I won’t start a rant about UML. I think its best use is for sketching some ideas.
Software engineers should find the first point, projects with no schedule were successful, to be of particular interest. How many times have you heard the results from the Standish Group that says 75% of projects were unsuccessful, meaning that they were late and over budget? Is that a real failure of the project, or do we just suck at estimating?
Popularity: 7% [?]
In the next few weeks, I will be going through the backlog of things I accumulated in the last months that I want to touch in this blog. The first one dates back from october, but ties in nicely with my last posts about CUSEC. It’s from Martin Fowler.
This approach – some people report their story, others copy it with or without success – is the backbone of how a profession can learn. The fact that it’s anecdotal doesn’t stop it from working – after all much of our entire economic system is built on people building on each others’ anecdotes of how businesses should be run.
It’s very tough in software engineering to come up with empirical evidence on a particular practice. Some would say it’s impossible. So we have to rely on anecdotes of what worked for someone on a particular project, in a specific context, with individuals, etc. There are a lot of variables involved which make it difficult to reproduce the practice in your situation. However, it’s the best we can get and it doesn’t mean we can’t learn anything. In fact, I would argue we learn more because it actually forces us to acknowledge the differences in what we’re doing and it forces us to better adapt to our circumstances.
It’s important for our profession that people discuss what they’ve tried, what worked for them, what didn’t, etc. This is why I think conferences like CUSEC are very important. It’s a place to gather and share our experiences. The presentation from Motorola on their adoption of agile practices is the best example of this.
Popularity: 6% [?]
Seen at Exploration Through Example
Soap opera tests exaggerate and complicate scenarios in the way that television soap operas exaggerate and complicate real life.
That one is just too funny to pass on. Next time you write a test case and want to come up with the worst scenario (everything going bad), imagine you are writing a soap opera.
Popularity: 3% [?]
sirenian: BDD: The campaign against testing
“Test”, in Test Driven Development, encapsulates the idea of specification, design, verification of implementation and the ability to confidently refactor. Regression testing itself is almost a by-product of these uses of the word “test”.(…)Don’t test; think “What should this class do? What are its roles and responsibilities? What does it do to the things I’m going to give to it?” Then write a method which will describe the class’s behaviour.
Words shape the way we think. I just found about behavior driven development (BDD). It’s a subtle change in terminology but it focuses more on what the tests really are trying to accomplish. I kinda like it.
BTW, read the article to find out what is a ScalpelSheepVisitor.
Popularity: 3% [?]
I just came across this. It is updated daily with links to interesting tools and articles related to programming.
Popularity: 3% [?]
Not everyone will enjoy the opportunity to learn something new. Some people will reject all of your attempts to have them try something new. Then it’s time to ask yourself if these people are truly contributing what you need contributed to the organization.
Another quote from Johana Rothman. If you are interested in management, I strongly suggest adding her blog to your news feeder.
This quote is a followup to my previous post. It’s something I have a bit of a problem with. I personaly like to always work on new stuff, to improve myself. I have trouble understanding people who don’t enjoy that also. It leads to situation where I think I’m proposing something interesting to someone and I end up a bit angry when I don’t get the expected answer.
Popularity: 3% [?]
The longer you hold a particular position in the organization, the more you need to consider coaching other people. If you become indispensable, you need to fire yourself from your current position and obtain a new one (in the same company is fine).
This might sound strange to some people, but for the good of the organization, you need people that will grow with it, that will adapt to change. You want people who are up to new challenge. But you also want them to help others, to coach them so that they can grow too.
Popularity: 3% [?]
Why are you planning to have enough bugs to need tracking?
Popularity: 3% [?]
I discovered that in the presence of SelfTestingCode, most bugs that static types would have were found just as easily by the tests.
Last night I was playing with rails trying to understand some of the features. Old habits kicked in. I did not write some tests and got bitten once again. Lost almost an hour on a few stupid typos. As Martin Fowler explains, tests are more important in a dynamic typed language as the compiler won’t catch some errors for you. Fortunately, rails supports testing right out of the box.
Popularity: 8% [?]
