Decades ago, when I was first learning programming, there were only a few interactive terminal systems on campus. You had batch programming with cards, usually. Now, it wasn't like the real old-timers - there were departemental staffers on hand to drop your card deck into the reader right when you showed up, but you often had to wait hours for your job to reach the front of the queue and your output to print. So it was costly to run a program with errors. The result of this was that I would spend a significant amount of time looking over my program for syntax errors, logic errors, etc. I had plenty of time to retype a card, but only so many read, queue, process, print runs I could fit into the day.
These days, its easy to compile and run. Heck, with interpreted languages, you don't even compile. And this seduces me into the problem this post talks about - One More Try. Now, this is different from a debugging session, because it might not be my code, and I might be looking for an issue in a library. But if I am writing new code, and I run it, find it fails, I'm way too easily lured into the rapid tweak/build/run cycle, and that leads to long nights, because I don't stop to see what's really happening. Sometimes I can't see it, but if I stop, look at the code, and decide where things might be going wrong, I can at least put log messages or other debug at the right places.
The Ninja Lesson - seek to understand the essence before you act to change it.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, June 13, 2008
Wednesday, June 11, 2008
Ninja Secrets of Software Development
I spent a good portion of today writing a filter, to prevent some destinations from being sent certain types of messages. I was essentially making a quick hack to cover for a failure in another group, the developers of the code at the destination that would incorrectly handle the messages. So I was having to write this fairly quickly, and get it into a testbed ASAP, so it could be verified as working, and sufficiently flexible to serve for the (hopefully) short period of time before the destination code is fixed.
The fact that I was having to read from a configuration file for the ID of the destinations to filter made me realize that a Software Ninja should follow the historical example, and have a bag of tricks handy for just such an emergency. When surprised by a pop-up deadline, the Software Ninja can throw caltrops on the trail to slow down pursuit, and escape. In this case, the caltrops would be snippets of pre-packaged code that can be quickly pasted into the project to solve the immediate problem, and later improved or removed as desired.
These snippets are not necessarily code residing in the project itself, but a collection of functions, methods, classes, and whatnot, kept in your private workspace, that you can use to mold changes in the project code when there is no existing code in the project to work with. It should be in whatever languages you develop in, and as you go, glean more from the project. You're looking for common small tasks that span all types of projects.
In my example, I needed to read a text file produced from a database unload, parse it into fields, and save some of the fields for later use, in a collection that resized as needed. It's teh type of routine you find in many projects, so I will add it to my bag of tricks.
And you can generalize them a little. It's quite common for the data source to change as a project evolves. It starts out as a flat file, grows to a CSV file dumped from a spreadsheet, then to a database table. Your snippets can relate to each other - have a flat file reader that can parse fields separated by arbitrary characters (strtok_r is your friend in C++, as split() is in Perl and Python), and a database table reader that pulls fields out of a table, and they feed into a routine that returns a dynamically-sized collection. If you're writing in Java, you may need a routine to read in properties files. For shell scripts,
a whole set of routines for reading from files, accessing databases via SQL, or grabbing a web page with curl may suit your needs.
So keep an eye out for useful snippets, and grab them for your collection. And the next time a manager springs a deadline on you, your Ninja response will throw pepper in their eyes and escape into the shadows.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
The fact that I was having to read from a configuration file for the ID of the destinations to filter made me realize that a Software Ninja should follow the historical example, and have a bag of tricks handy for just such an emergency. When surprised by a pop-up deadline, the Software Ninja can throw caltrops on the trail to slow down pursuit, and escape. In this case, the caltrops would be snippets of pre-packaged code that can be quickly pasted into the project to solve the immediate problem, and later improved or removed as desired.
These snippets are not necessarily code residing in the project itself, but a collection of functions, methods, classes, and whatnot, kept in your private workspace, that you can use to mold changes in the project code when there is no existing code in the project to work with. It should be in whatever languages you develop in, and as you go, glean more from the project. You're looking for common small tasks that span all types of projects.
In my example, I needed to read a text file produced from a database unload, parse it into fields, and save some of the fields for later use, in a collection that resized as needed. It's teh type of routine you find in many projects, so I will add it to my bag of tricks.
And you can generalize them a little. It's quite common for the data source to change as a project evolves. It starts out as a flat file, grows to a CSV file dumped from a spreadsheet, then to a database table. Your snippets can relate to each other - have a flat file reader that can parse fields separated by arbitrary characters (strtok_r is your friend in C++, as split() is in Perl and Python), and a database table reader that pulls fields out of a table, and they feed into a routine that returns a dynamically-sized collection. If you're writing in Java, you may need a routine to read in properties files. For shell scripts,
a whole set of routines for reading from files, accessing databases via SQL, or grabbing a web page with curl may suit your needs.
So keep an eye out for useful snippets, and grab them for your collection. And the next time a manager springs a deadline on you, your Ninja response will throw pepper in their eyes and escape into the shadows.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Subscribe to:
Posts (Atom)