Every once in a while, you hear the infamous words "That should only take 15 minutes to fix" - often spoken by someone who isn't a professional software developer. While it is true that a number of bugs can be rectified rather quickly - think: typo or simple inversion of logic - the change in the source code is only a tiny part of the process.
At my day-job, we have to pay extreme attention to the accurate workings of our software. As we cater to the healthcare indsutry, the lives of patients may well depend on our software. The physicians need acuurate data to apply the best treatment, so it is our duty that we correctly handle all the input coming into our laboratory informaton system, as well as the output we produce in the form of reports or data exchange with the general hospital system.
This means we follow a strict procedure for every modification to the source code: analysis -> analysis review -> code -> code review -> unit test -> integration test -> documentation + localisation -> final review. Exhaustive test plans are executed at every release to ensure that the software is reliable and that one change doesn't have a hidden impact on another part of the system. And that's something which simply can't be done in a quarter of an hour.
Even then, you can never be sure that your program will doexectly what it's supposed to do. There are many internal and external variables at play - and even if a computer is supposed to be a deterministic system, where the exact same actions should have the exact same result, errors do occur that are sometimes hard to figure out. Computer software is a composition of many layers - hardware, operating system, frameworks, libraries - most of which are outside of our control.
Yet we all rely on technology and the building blocks we have, to build new functionality, patch existing code and sometimes make radical changes. And we hope that the person who built that underlying layer, is at least as smart as we are, and caught all the mistakes before that layer came to us for further use. Looking at the giant software companies' bug lists may leave you in a bit of a shock when you see thousands upon thousands of entries, some lingering for a decade.
Is it all gloom and despair though? Definitely not - there are plenty of good practices we as developers can and should apply. Where I used to only care about producing the code for the features, I now take the time to write tests for my code, and run my libraries and applications through a battery of manual tests before releasing them into the wild. That sure prevents a lot of frustration for testers and myself, yet even with all that care, sme things are bound to pop up in the field.
A quick internal build for test purposes may only take 15 minutes - but a real solution, fully tested and vetted, that can't be done in such a timeframe.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
Saturday, February 28, 2009
Saturday, January 3, 2009
Revolution newsletter articles
One of the best things about Revolution is its strong-knit community - whether it's on the mailing list or on the forums, when you post a question there's bound to come an answer from one of the many users that have faced a similar problem. And soon enough, the newbies come of age and start replying to questions as well. This way, the good advice keeps getting spread over an ever-growing group of users.
Another important resource is the Revolution newsletter, where both the company's engineers and a variety of writers from the uer community share their knowledge and their solutions for challenges encountered while developing their applications. I just concluded a series of articles on using the 'merge' function, which got good reader feedback.
The 'merge' function is one of those extremely helpful weapons in the Revolution armoury, which every developer should know about and use, as it has many applications and can save you a lot of time. It goes through a text, and evaluates expressions that you've put in between [[...]] double square brackets, and executes statements that you've put in between <?...?> processing instruction brackets; and when it's done, it hands you back the end result.
This makes it an ideal tool for assembling HTML pages, RTF documents, XML files and other text-based file formats. But you can also use it as a preprocessor for templates, ranging from SQL queries to VBScript or AppleScript. One particular combination is to use Microsoft Word as a reporting system in two ways: merging an RTF template into a document, and then merging the necessary script to automate Word and print the document for you.
Here are links to the individual articles:
- The Power of Merge (revUp | Issue 55 | August 18th, 2008)
- The Word of Merge - part 1 (revUp | Issue 61 | November 20th, 2008)
- The Word of Merge - part 2 (revUp | Issue 62 | December 22nd, 2008)
Enjoy the articles and Revolution! And if you still have to make a New Year's resolution, make it something along the lines of 'I want to learn' - as education is the only path that leads to prosperity...
Another important resource is the Revolution newsletter, where both the company's engineers and a variety of writers from the uer community share their knowledge and their solutions for challenges encountered while developing their applications. I just concluded a series of articles on using the 'merge' function, which got good reader feedback.
The 'merge' function is one of those extremely helpful weapons in the Revolution armoury, which every developer should know about and use, as it has many applications and can save you a lot of time. It goes through a text, and evaluates expressions that you've put in between [[...]] double square brackets, and executes statements that you've put in between <?...?> processing instruction brackets; and when it's done, it hands you back the end result.
This makes it an ideal tool for assembling HTML pages, RTF documents, XML files and other text-based file formats. But you can also use it as a preprocessor for templates, ranging from SQL queries to VBScript or AppleScript. One particular combination is to use Microsoft Word as a reporting system in two ways: merging an RTF template into a document, and then merging the necessary script to automate Word and print the document for you.
Here are links to the individual articles:
- The Power of Merge (revUp | Issue 55 | August 18th, 2008)
- The Word of Merge - part 1 (revUp | Issue 61 | November 20th, 2008)
- The Word of Merge - part 2 (revUp | Issue 62 | December 22nd, 2008)
Enjoy the articles and Revolution! And if you still have to make a New Year's resolution, make it something along the lines of 'I want to learn' - as education is the only path that leads to prosperity...
Thursday, August 7, 2008
The Programmer Syndrome
No, it's not as if all developers exhibit the same behaviours or nervous tics - but a lot of us tend to suffer from two less-than-stellar character traits: the "Not Invented Here" syndrome and its nefarious cousin "I've always done it this way". Not exactly what you're looking for in an industry where there's a continuing debate about code reuse.
Of course it is a lot more fun to claim you're at the forefront of technology and innovation, but half of the time we're just rehashing the same technology - message queues are about as old as UN*X and let's not even talk about the Network Computer brouha. And sometimes this running in circles makes us blind and turn us into snooty stubborn time-wasters. If you're wondering what triggered this post, well twice this week have I been confronted with this near-pathological behaviour.
The first occasion was reading one colleague's analysis for a new logging system to better track changes at the record level. Obviously an important feature that should be done right, and in this case the idea was to extend the logging features currently present in the application - thumbs up in the reuse department. What struck me as odd about it, was that he didn't want to adopt the auditing system that was added to the underlying database system in a not too distant past. What really irked me about it, was that he didn't even mention it and didn't bother to express a good reason as to why we shouldn't use the built-in mechanism.
The second occasion was when a colleague started to explain how they solved a certain asynchronous data processing problem at his previous job, in what we can euphemistically call a 1980's solution: have an external process poll the database every minute. And he insisted that this was the only robust way to do it, and it worked fast because they had hundreds of these batch processes running on an IBM RS-6000. As the problem unfolded, he had to add more and more checks and balances to counteract concurrent modifications by different processes. When I suggested that for this particular situation a message queue might be more appropriate, he dismissed it as costly and overcomplicated. I don't know about you, but message queues are generally built by very smart people who have thought through the different corner cases, and I'll happily follow their path.
Naturally, as we have creative minds (and no, it's not because we express ourselves through code rather than music or painting that we shouldn't be considered "creative") we seek challenges and aim for the sky when we decide not to fix the code but rewrite it - paraphrasing Captain Jack Sparrow: "a bigger boat, a better boat, that boat." And it is extremely important to deliver something that we feel proud of, which is what drives us to work insane hours and then some more, just to get it done by this impossible deadline with more features than were in the requirements.
But aren't we sometimes overdoing it by completely ripping something apart and replacing it with an alternative that lives up to our current standards? None of us were born with programming experience, we all had to learn through "Hello, world!" in a dozen programming languages, and if all is right, we're still learning new things every day. Yet with an ever-growing to do-list and much longer to research-list, I prefer not to duplicate efforts. Which is why open source libraries, with the right licensing policy, are a great blessing.
Steering back to the topic, I feel this interview with Joshua Bloch is a must-read. Joshua Bloch is the author of Effective Java, considered by many to be among the best books on how to use the Java programming language. Here's the single-best quote from that interview: "In order to stay sane, most developers have a can-do attitude, and some take it too far. They say to themselves, 'Yes, there's a library, but I can do better.' Maybe you can, but that doesn't mean you should."
Mind you, when I recently rebuilt a monitoring tool, I did scrap nearly 90% of the existing code and replaced it with new code that made as much use as possible of new features added in recent versions of Java. So please do not read the above as a mindless "holier-than-thou" rant about short-sighted colleagues. What I really hope, is that you remember to keep an open mind, learn about what's waiting for you to use in your applications - either in the core of your development libraries or in what's available from the outside world. And if you do roll your own, at least make a list of the arguments pro and contra.
Of course it is a lot more fun to claim you're at the forefront of technology and innovation, but half of the time we're just rehashing the same technology - message queues are about as old as UN*X and let's not even talk about the Network Computer brouha. And sometimes this running in circles makes us blind and turn us into snooty stubborn time-wasters. If you're wondering what triggered this post, well twice this week have I been confronted with this near-pathological behaviour.
The first occasion was reading one colleague's analysis for a new logging system to better track changes at the record level. Obviously an important feature that should be done right, and in this case the idea was to extend the logging features currently present in the application - thumbs up in the reuse department. What struck me as odd about it, was that he didn't want to adopt the auditing system that was added to the underlying database system in a not too distant past. What really irked me about it, was that he didn't even mention it and didn't bother to express a good reason as to why we shouldn't use the built-in mechanism.
The second occasion was when a colleague started to explain how they solved a certain asynchronous data processing problem at his previous job, in what we can euphemistically call a 1980's solution: have an external process poll the database every minute. And he insisted that this was the only robust way to do it, and it worked fast because they had hundreds of these batch processes running on an IBM RS-6000. As the problem unfolded, he had to add more and more checks and balances to counteract concurrent modifications by different processes. When I suggested that for this particular situation a message queue might be more appropriate, he dismissed it as costly and overcomplicated. I don't know about you, but message queues are generally built by very smart people who have thought through the different corner cases, and I'll happily follow their path.
Naturally, as we have creative minds (and no, it's not because we express ourselves through code rather than music or painting that we shouldn't be considered "creative") we seek challenges and aim for the sky when we decide not to fix the code but rewrite it - paraphrasing Captain Jack Sparrow: "a bigger boat, a better boat, that boat." And it is extremely important to deliver something that we feel proud of, which is what drives us to work insane hours and then some more, just to get it done by this impossible deadline with more features than were in the requirements.
But aren't we sometimes overdoing it by completely ripping something apart and replacing it with an alternative that lives up to our current standards? None of us were born with programming experience, we all had to learn through "Hello, world!" in a dozen programming languages, and if all is right, we're still learning new things every day. Yet with an ever-growing to do-list and much longer to research-list, I prefer not to duplicate efforts. Which is why open source libraries, with the right licensing policy, are a great blessing.
Steering back to the topic, I feel this interview with Joshua Bloch is a must-read. Joshua Bloch is the author of Effective Java, considered by many to be among the best books on how to use the Java programming language. Here's the single-best quote from that interview: "In order to stay sane, most developers have a can-do attitude, and some take it too far. They say to themselves, 'Yes, there's a library, but I can do better.' Maybe you can, but that doesn't mean you should."
Mind you, when I recently rebuilt a monitoring tool, I did scrap nearly 90% of the existing code and replaced it with new code that made as much use as possible of new features added in recent versions of Java. So please do not read the above as a mindless "holier-than-thou" rant about short-sighted colleagues. What I really hope, is that you remember to keep an open mind, learn about what's waiting for you to use in your applications - either in the core of your development libraries or in what's available from the outside world. And if you do roll your own, at least make a list of the arguments pro and contra.
Subscribe to:
Posts (Atom)