Saturday, March 25, 2006
Wednesday, March 15, 2006
Good and evil of software platforms
“some sort of framework, either in hardware or software, which allows software to run. Typical platforms include a computer's architecture, operating system, or programming languages and their runtime libraries.”Business requirements driven platforms
Lately I've heard an opinion of one manager that the platform features should be driven by the business requirements and then these features will enable the concrete products. As an agile methods supporter I immediately became suspicious: anything that does not directly add value is over-design and are very likely to be useless and harmful.
The danger is in the fact that the business requirements discovered by some business analysts might simply hang in the air without the real link to the implementation, while various project will struggle trying to do the concrete things what their concrete customers want. The horizontal platform can easily become unbalanced, with too much effort put into never used features while some other components are not flexible enough.
Project driven platforms
As Joel Spolsky correctly notes:
“It's really, really important to figure out if your product is a platform or not, because platforms need to be marketed in a very different way to be successful. That's because a platform needs to appeal to developers first and foremost, not end users.”The crucial mistake of business requirements driven approach is the assumption that these are the end-users who are the target audience. They are not. The platform customers are the developers and concrete projects.
Good and evil
So are the horizontal platforms evil? Not really. System libraries are useful, encourage the code reuse and save the developers from the unneeded low-level details. The only thing the platform designers should pay big attention to is who the actual platform customer is and how exactly the platform helps them. Platform driven by the [generalized] project requirements greatly facilitates the application development and exactly at the points where help is needed.
What is your experience with the platforms? What of the platforms you used was the most useful and why?
Tuesday, March 14, 2006
Overagiling in testing
Agile methods have some great things going on with regards to testing, but we’ve been set back by a lot of bad testing folklore that was rehashed under the “Agile Testing” banner in early writings. Sometimes ridiculous claims that software testers have heard for years were once again trotted out as “wisdom”, such as “manual tests are harmful”, or “every test must be automated”, or “testers are the Quality gatekeepers on a project”.Via IndicThreads
Recently, I’ve worked with more and more developers who were misled by the “Agile-Testing” folklore that automated unit testing encompasses software testing.
Monday, March 13, 2006
After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.
Attend these valuable tutorials:
Eliminating Collaboration: Get More Done Alone by Jean Tabaka
Making Outsourcing Work: One Team Member per Continent by Babu Bhat
User Stories and Other Lies Users Tell Us by Mike Cohn
FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham
Saturday, March 11, 2006
Mika talks on the ways of error handling in software and how the developer can aid the error handling:
- You may need to document specific errors and supply additional information to the immediate caller.
- The error information must support generic handling strategies, like a blind retry.
- Low-level exceptions should not be remapped by upper layers.
- The routine detecting an error is responsible for describing it in terms understandable to a human, often the user.
- The system must be able to tell the user if they should contact another human.
- The system must produce different messages for consumption by different humans.
Friday, March 10, 2006
Toyota's Five Why's
There are few simple principles behind the Toyota quality system. Here are two of them:
Quality is not something that is added at the end of the production line. Every major robot that works on the car parts has sensors and intelligence to recognize defects early and either fix them or remove the detail from the line.
- Toyota's five why's
Whenever the problem occurred, the engineers ask why. Once they identified the factors that led to it, they investigate the reasons for these factors to happen. This process is repeated until no new information is forthcoming. Usually five levels of investigation is enough, therefore the technique is called "five why's"
Does it pay off? - Ask Toyota.
Thanks to Lasse Koskela for the idea of this post
Thursday, March 09, 2006
New feed address
Wednesday, March 08, 2006
Do you own your code?
It is quite often that particular modules are "owned" by particular people and only they are allowed to make reasonable changes there. Usual argument is "The person, who doesn't know the module, can unintentionally break it".
What is interesting is why is it easily possible to the fellow programmer to break the code easily. After all he is often as experienced as the author of the code. The sad answer could be that the code is hardly understandable, too complex, not well commented or doesn't have enough unit tests to prevent the regression. Most of agile development methods promote: 1) fixing, testing and finishing the existing code, before adding new features; 2) test-driven development; 3) common code ownership; 4) frequent peer code reviews. The first two items help to cope with the "can unintentionally break it" part of the argument, the last two - with the "the person who doesn't know the code"
Next time you will hear that somebody should have an "own" module, ask the speaker for the reasons and tell about the known cures for the "code ownership syndrome".
Thanks to the F-Secure person (sorry, still don't know his name) who shared with me the arguments presented in the post
Monday, March 06, 2006
Test the platform
One of the topics discussed was Test Driven Development (TDD). It is the software development method, when programmer first creates the unit test for the new functionality and only then implements it. I had the concern about the unknown platform capabilities. It happens so, that I and my colleagues often work on fresh betas of the coming software platforms that don't have all the new features documented or even implemented. Therefore quite often I don't have a concrete plan in mind. I try using one feature and another until I find a way that satisfies the original requirements somehow. Of course, these feature trials tend to become the release code and it's mentally difficult to write a unit test after the code - after all this way it is not TDD anymore.
The solution proposed by somebody from F-Secure (sorry, I don't know the name. Please, comment if you know) was as simple as every ingenious idea. If you are unsure about the platform features, create unit tests for them. It might not be possible for the GUI area, when you have to observe the results manually, but for all the other areas such tests would be a good compatibility test and a good starting point when you'll have to port your application to the next version of the platform.
Sunday, March 05, 2006
Agile SW Development Practices Seminar
At the moment I can present my main impression: all the agile methods are about is truth and visibility. Don't lie to yourself; don't overplan, what you are not going to implement; don't pretend the project is 95% ready, if you are expecting endless bugfixes and don't hide the current situation from your customers. That's it. All the remaining details are about how to implement these principles in practice. I.e. how often and in which terms to report to customers so that they understood you and weren't overloaded with the unnecessary details, how to prevent yourself from overplanning, etc.