I'm as guilty of programming faults as anyone, but there's a vein of blame-the-programmers running through the blogosphere. Here's one example, discussing the tendency for programmers to develop in isolation and drop a finished product into the code line, where it's difficult for colleagues to analyze and understand for review.
What is not discussed is the environment that supports this. In many shops, the number of projects exceeds the number of developers, so everyone is always in the middle of multiple features, and the management rarely considers code reviews a worthwhile expenditure of time. It is hard to get the time for a final review, much less getting time from the 2-5 developers to review code in progress multiple times. The XP practice of Pair-Programming is one way to get at least one pair of eyes on code at all stages is also a hard sell to management - they see it as cutting their staff in half, and they already have too much to do!
Another issue is the type of criticism that we tend to get. Many of us are not well-suited to give constructive ciritcism. A cow-orker of mine is prone to call code not meeting her peculiar standards "bullshit" or "stupid", even if it meets the requirements provided the developer. I'm not partial to having such words applied to my efforts, especially if it's early in the development when my ideas are not fully formed.
But even if the programmers are less harsh, the fact remains that managers do not see reviews as progress, and it's rare to get the time to do them.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, June 22, 2008
The Limits of Self-Organization
I ran across this about a month ago, and it struck a nerve.
Now, as my previous entries will show, I'm not a big fan of typical corporate management, with the political games, favoritism, bad decision-making, etc. But I will step up to defend management in a corporation as being the only ones capable of doing a necessary job - keeping focus on the corporate target.
The post I read laments that at a conference, self-organization was a virtue, while it seems lacking in the company he works at. But there is a key difference - the corporation has a goal that is not defined by the participants, and management is the one group that can keep development from mistaking the intent of that goal.
Sometimes the corporate goal is just plain boring - and the developers, as we are wont to do, will want to add something to make things interesting, which will introduce risk.
Now, the Extreme Programming mavens will leap to claim that the developers will not add features that are not covered by a user story. True enough, but a department that is using XP will also have better communications - not a typical corporation.
So it seems a little odd to blame the developers for lacking initiative without blaming the corporate management for making them need more info.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Now, as my previous entries will show, I'm not a big fan of typical corporate management, with the political games, favoritism, bad decision-making, etc. But I will step up to defend management in a corporation as being the only ones capable of doing a necessary job - keeping focus on the corporate target.
The post I read laments that at a conference, self-organization was a virtue, while it seems lacking in the company he works at. But there is a key difference - the corporation has a goal that is not defined by the participants, and management is the one group that can keep development from mistaking the intent of that goal.
Sometimes the corporate goal is just plain boring - and the developers, as we are wont to do, will want to add something to make things interesting, which will introduce risk.
Now, the Extreme Programming mavens will leap to claim that the developers will not add features that are not covered by a user story. True enough, but a department that is using XP will also have better communications - not a typical corporation.
So it seems a little odd to blame the developers for lacking initiative without blaming the corporate management for making them need more info.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, June 20, 2008
Speed Coding
One of the more interesting analogies I've seen recently in programming practice is the equating of programming, a mental skill, with a physical skill (karate, painting, etc). This has been expressed as the Code Kata, Code Kumite, and as Software as Performance Art, among other examples.
This idea get the Ninja Seal of Approval(tm). I wish I practiced it more often. Normally, a developer will do this when learning a new language - we take a problem we've done before, and redo it in the new language, honing the program with our experience. We less often work the improvement within a language we already know - improving the performance or the storage, or simplifying it.
For some of us, the projects we are working on have sufficient growth to allow us to improve the speed or memory usage as part of the routine software maintenance. If we don't get this, perhaps we should think about these drills in programming as part of our mental exercises.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
This idea get the Ninja Seal of Approval(tm). I wish I practiced it more often. Normally, a developer will do this when learning a new language - we take a problem we've done before, and redo it in the new language, honing the program with our experience. We less often work the improvement within a language we already know - improving the performance or the storage, or simplifying it.
For some of us, the projects we are working on have sufficient growth to allow us to improve the speed or memory usage as part of the routine software maintenance. If we don't get this, perhaps we should think about these drills in programming as part of our mental exercises.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Programmer Macho
Programmers are as competitive as anyone else, but since much of our work is mental, and therefor difficult to judge at a glance, we look to what we used to build the system as the criterion for success.
Of course, being the fractious sorts that we are, we all are using different yardsticks. Some judge by the age of the language, or the esoteric-ness of the language, or the purity of expression, popularity, or even the proximity to machine code.
We have our art school types, who champion languages that nobody else uses, and drop them when they become "common", and our Utilitarianists - the best language is the one that more people are using.
We often consider the things we know best as the standard, and other opinions be damned.
Some of it is protection of our investment - of time, of effort, of mental space. Some of it is our almost innate urge to put our own 2 cents in, and some may just be truth.
Of course, telling the difference is the trick. Let me know if you have a trick to tell this.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Of course, being the fractious sorts that we are, we all are using different yardsticks. Some judge by the age of the language, or the esoteric-ness of the language, or the purity of expression, popularity, or even the proximity to machine code.
We have our art school types, who champion languages that nobody else uses, and drop them when they become "common", and our Utilitarianists - the best language is the one that more people are using.
We often consider the things we know best as the standard, and other opinions be damned.
Some of it is protection of our investment - of time, of effort, of mental space. Some of it is our almost innate urge to put our own 2 cents in, and some may just be truth.
Of course, telling the difference is the trick. Let me know if you have a trick to tell this.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Sunday, June 15, 2008
Killer (Ninja) Instincts
As quite a few people writing about programming have noted, there is a strong vein of creativity in programming. The feeling when that flash hits your brain is one of the coolest things in the world.
I've always said that programming is weaving with logic - building from thought itself. And so when those insights arrive, its unreal.
After a number of years programming, you start to have a sense of "rightness" about the direction your are taking with code, as this blog post notes. Sometimes it's a vague feeling, and sometimes it's a solid idea. If you get one of these feeling, GO WITH IT!
Every time I've failed to listen to this little voice in my head, I've seen the programming so sour. Typically, at the current stage of my career, it's been architectural issues, but they can be at any portion of the development process.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
I've always said that programming is weaving with logic - building from thought itself. And so when those insights arrive, its unreal.
After a number of years programming, you start to have a sense of "rightness" about the direction your are taking with code, as this blog post notes. Sometimes it's a vague feeling, and sometimes it's a solid idea. If you get one of these feeling, GO WITH IT!
Every time I've failed to listen to this little voice in my head, I've seen the programming so sour. Typically, at the current stage of my career, it's been architectural issues, but they can be at any portion of the development process.
Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP
Friday, June 13, 2008
Lost in My Own Code
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
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
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)