- Use lots of spaces.
- Cram everything together without any spaces.
- Align code in arbitrary places.
- Make up really long variable and function names.
- Make up random variable names that don't match the data.
- Make up random function names that hide or obscure the code that is executing.
- Use 1 character variable names.
- Rewrite the same functions a dozen or so times.
- Guess, write some code, toss it out and then guess again...
- Sit around in meetings every day.
- Stand around in meetings every day.
- Avoid all meetings.
- Procrastinate about getting organized.
- Get organized about procrastinating.
- Get clever (monkeys are clever …)
- Comment about the obvious aspects of the code.
- Don't comment about the weirdness of the code.
- Apply a hastily thought-out patch.
- Add in extra lines of code in the hopes that somehow, that will make it better.
- Change everything at the last moment.
- Continuously ignore a serious problem or miscommunication.
- Watch someone else type.
- Write a test for something that would be obvious if it were wrong.
- Write a test for something that ain’t never going to happen.
- Write a test to test if a test is working.
- Re-invent something that has been in textbooks for decades.
- Rely on something that kinda works, instead of spending the time to build something that actually works.
- Take technical advice from non-programmers.
- Ignore domain or usability complaints from the users.
- Ignore the users.
- Yell at the users for not being to use unusable software.
- Assume (pretty much anything).
- Believe in the marketing documentation, without reading the specs first.
- Design an ugly user interface (and refuse to believe that it is ugly).
- Write documentation that absolutely nobody will read and if they did, couldn’t glean any useful information from.
- Make pretty diagrams. Lots and lots of pretty diagrams.
- Build something large without a design or blueprints.
- Build something small and expect it to magically grow into something large.
- Refuse to provide any information.
- Provide too much information(s).
- Wait for the magic to happen.
- Ignore what everyone else is doing, and get super, super, super creative.
Monday, March 28, 2011
How to Waste Your Time While Programming
Fun ways to kill off programming productivity:
Friday, March 25, 2011
Greed and the Ownership of Data
Data is a virtual set of symbolic tokens representing things in the real world. It does take some effort to type in, to correct and to store it in a large database, but ultimately the data itself is just a reflection of the world around us. In some of the Social Networking sites, the main work in collecting the data is the participants themselves. Because of that, they have an implicit say in how the data is used or abused. If they’ve chosen to trust a company enough to allow them to have the data, and they haven’t explicitly insisted that it is private data, then the presumption is that it is for public consumption. Given that the information is about things in the real world, and that it has been maintained and corrected by a third party, the only claim a site can have to it is that it has cost them something to set up the infrastructure and something to maintain the storage. Is that enough to say that they own the data?
If I’ve typed my info into a social site, and I have the expectation that the information is made public, or can be made public, then because it is information about me or some aspects of my world I find it very hard to believe that someone else can “own” it. I do understand the need to monetize their work to make back any investments, but sites have to do that with their own efforts, not mine. What’s mine is mine, and if I have given it away, then it is available for everybody, not just some clever hackers with a desire to get rich quickly. If the company had come to me, done the analysis and then all of the data entry, I could see that as a different story; they produced the information, not me. But when I am the producer, I take someone trying to stake a claim on my work as their own, as being excessively greedy. “Owning” data is questionable, but owning data that you grabbed from someone else is stepping over a line.
If I’ve typed my info into a social site, and I have the expectation that the information is made public, or can be made public, then because it is information about me or some aspects of my world I find it very hard to believe that someone else can “own” it. I do understand the need to monetize their work to make back any investments, but sites have to do that with their own efforts, not mine. What’s mine is mine, and if I have given it away, then it is available for everybody, not just some clever hackers with a desire to get rich quickly. If the company had come to me, done the analysis and then all of the data entry, I could see that as a different story; they produced the information, not me. But when I am the producer, I take someone trying to stake a claim on my work as their own, as being excessively greedy. “Owning” data is questionable, but owning data that you grabbed from someone else is stepping over a line.
Monday, March 21, 2011
Patents and Routine Engineering
One of the great evils of the 21st century is our system of patents. I’m guessing that they were devised to help the little guy not get plowed over my the 200 pound gorillas out there, but these days they do anything but that. They’re just tools to try and force an unwarranted monopoly on an existing market.
What really irks me is when someone gets away with claiming they own ‘routine engineering’. Some guy writes some unspectacular code that is slightly different than the current, growing and ever changing conventions. Clearly a derivative work. Nothing awesome, but just a minor tick better. Then if he’s at a big shop, a horde of lawyers descend and turn that into something that they can fight about later. Ick.
One way to kick patent trolls is to limit damages to lost revenue. No product? Then no damages. Also, make it illegal to sell the patents by themselves. If they want the patent, they have to buy the whole division that produces the relevant product. And it wouldn’t hurt to limit the patent down to five years or so; not an entire generation’s worth of twenty.
Another thing to do is not allow obvious patents. That is, no one should ever be allowed to patent something trivial like an ‘on switch’ for which you have no choice but to add it. That also applies to some of these NUI patents. You have to interact, that’s clearly prior art, so the actual specifics of how that is done is just a derivative. If someone is too close, that’s what trademarks are for ...
Even better would be to make it possible for the little guy to actually protect their work too, instead of just the behemoths. What’s the point of a set of laws if they doesn’t actually do what they were intended to do.
What I’d be in favor of is forming a new ‘international’ patent office. One that handles this in a fair way on a world-wide basis. Just to make it more interesting, not only would you have to have a product that was affected, but you’d also have to have it in a common local market with the offender, in order to claim compensation. Also, an option to have the patent granted, but not fully filed (to make it cheaper for both the submitting and the checking) would help. People could write up crude patents for a small fee, but only go through the legal nightmare if there was an issue. If they never get a product to market, then their patents would be useless (and never need to be checked).
Patents suck. It’s about time someone fixed them.
What really irks me is when someone gets away with claiming they own ‘routine engineering’. Some guy writes some unspectacular code that is slightly different than the current, growing and ever changing conventions. Clearly a derivative work. Nothing awesome, but just a minor tick better. Then if he’s at a big shop, a horde of lawyers descend and turn that into something that they can fight about later. Ick.
One way to kick patent trolls is to limit damages to lost revenue. No product? Then no damages. Also, make it illegal to sell the patents by themselves. If they want the patent, they have to buy the whole division that produces the relevant product. And it wouldn’t hurt to limit the patent down to five years or so; not an entire generation’s worth of twenty.
Another thing to do is not allow obvious patents. That is, no one should ever be allowed to patent something trivial like an ‘on switch’ for which you have no choice but to add it. That also applies to some of these NUI patents. You have to interact, that’s clearly prior art, so the actual specifics of how that is done is just a derivative. If someone is too close, that’s what trademarks are for ...
Even better would be to make it possible for the little guy to actually protect their work too, instead of just the behemoths. What’s the point of a set of laws if they doesn’t actually do what they were intended to do.
What I’d be in favor of is forming a new ‘international’ patent office. One that handles this in a fair way on a world-wide basis. Just to make it more interesting, not only would you have to have a product that was affected, but you’d also have to have it in a common local market with the offender, in order to claim compensation. Also, an option to have the patent granted, but not fully filed (to make it cheaper for both the submitting and the checking) would help. People could write up crude patents for a small fee, but only go through the legal nightmare if there was an issue. If they never get a product to market, then their patents would be useless (and never need to be checked).
Patents suck. It’s about time someone fixed them.
Sunday, March 20, 2011
Failure
Lately my friend has been noticing that the editor in NetBeans occasionally refuses to save his edits. He can hit save all he wants, but until he restarts the IDE, the files on the disk are not being updated.
Yesterday, I did a bit of work in NetBeans using the jVi plugin, but this morning I noticed that my edits were gone. I likely saved many times as I often hit :w just because way back in the early days we couldn’t trust that a machine would stay up for very long, and that old habit of constantly saving became automatic. I can’t remember if I compiled the changes or not.
I worked for just over an hour and wrote several new methods. Hours later, I shutdown the machine. The version of NetBeans I’m using at home on my Linux box is 6.8, and my friend is using 6.9 on Windows.
I’m not entirely sure of what is happening, since in my case the editor is a vi-like plugin, and in my friends it is the default editor. Our versions are different as well. Perhaps in my efforts, I forgot to ever save (which would be highly unusual for me), but certainly during shutdown there were no dialogs or messages that I saw. It was a normal shutdown. Certainly for my friend, he clearly demonstrated that the ‘Save’ button was being pressed (multiple times), yet the file was not being updated.
Mostly likely it is some sort of threading problem. These seem to be the bug du jour, replacing the ever irritating ‘loose pointer’ in C. Threading is far easier to write then it is to understand, and problems with it are easily missed (or ignored) in light-weight testing. Thus we are inundated with simple race conditions that cause infrequent problems.
What I am sure of, is that if there is anything you really want and need from an IDE, it is the ability to save your work and know that it is saved.
Way back in the early days, when things were a little more chaotic, it wasn’t unusual to work for a while, forget to hit save and lose a lot of effort. Gradually, over the years this situation was fixed in a number of different ways. Microsoft Word can make frequent backups, some programs like Google Docs save every few minutes. And of course we have source code control, so it would be easy to have a bunch of revisions stored automatically, allowing a user to move seamlessly between them in the advent of a problem, or even tap a need for a longer reaching undo.
Basically this is a solved problem. Collectively we have many ways of insuring that once entered, none of our work is ever lost, and we could even have the option of moving forward and backwards through it to undo or redo any operation made over a very long period.
This is one of the key benefits to using a computer. We can automate our efforts, and allow that automation to be tracked, examined and replayed as necessary. Computers are great at remembering things.
It doesn’t really matter how many fancy cool features a piece of software provides if it can’t do the basics. For an editor or IDE, it doesn’t get any simpler than being able to reliably save a file. Nothing is more irritating in software than to have a program lose your work, when we all know that that doesn’t have to happen.
In the end, software is only usable if you can trust it. And when that trust is broken you have no choice but to conclude that the software is badly written. There is absolutely no acceptable reason in the 21st century for a major tool like an IDE to still be suffering from a simple problem that was solved (and removed) decades ago.
But I guess everything old is new again, and so a few programmers have graciously allowed us to revisit old demons that should have stayed hidden in the past. Perhaps my excessive saving habit will come in really useful again.
Yesterday, I did a bit of work in NetBeans using the jVi plugin, but this morning I noticed that my edits were gone. I likely saved many times as I often hit :w just because way back in the early days we couldn’t trust that a machine would stay up for very long, and that old habit of constantly saving became automatic. I can’t remember if I compiled the changes or not.
I worked for just over an hour and wrote several new methods. Hours later, I shutdown the machine. The version of NetBeans I’m using at home on my Linux box is 6.8, and my friend is using 6.9 on Windows.
I’m not entirely sure of what is happening, since in my case the editor is a vi-like plugin, and in my friends it is the default editor. Our versions are different as well. Perhaps in my efforts, I forgot to ever save (which would be highly unusual for me), but certainly during shutdown there were no dialogs or messages that I saw. It was a normal shutdown. Certainly for my friend, he clearly demonstrated that the ‘Save’ button was being pressed (multiple times), yet the file was not being updated.
Mostly likely it is some sort of threading problem. These seem to be the bug du jour, replacing the ever irritating ‘loose pointer’ in C. Threading is far easier to write then it is to understand, and problems with it are easily missed (or ignored) in light-weight testing. Thus we are inundated with simple race conditions that cause infrequent problems.
What I am sure of, is that if there is anything you really want and need from an IDE, it is the ability to save your work and know that it is saved.
Way back in the early days, when things were a little more chaotic, it wasn’t unusual to work for a while, forget to hit save and lose a lot of effort. Gradually, over the years this situation was fixed in a number of different ways. Microsoft Word can make frequent backups, some programs like Google Docs save every few minutes. And of course we have source code control, so it would be easy to have a bunch of revisions stored automatically, allowing a user to move seamlessly between them in the advent of a problem, or even tap a need for a longer reaching undo.
Basically this is a solved problem. Collectively we have many ways of insuring that once entered, none of our work is ever lost, and we could even have the option of moving forward and backwards through it to undo or redo any operation made over a very long period.
This is one of the key benefits to using a computer. We can automate our efforts, and allow that automation to be tracked, examined and replayed as necessary. Computers are great at remembering things.
It doesn’t really matter how many fancy cool features a piece of software provides if it can’t do the basics. For an editor or IDE, it doesn’t get any simpler than being able to reliably save a file. Nothing is more irritating in software than to have a program lose your work, when we all know that that doesn’t have to happen.
In the end, software is only usable if you can trust it. And when that trust is broken you have no choice but to conclude that the software is badly written. There is absolutely no acceptable reason in the 21st century for a major tool like an IDE to still be suffering from a simple problem that was solved (and removed) decades ago.
But I guess everything old is new again, and so a few programmers have graciously allowed us to revisit old demons that should have stayed hidden in the past. Perhaps my excessive saving habit will come in really useful again.
Wednesday, March 9, 2011
One Eye Open
In the land of the blind, the one-eyed man is king.
[In regione caecorum rex est luscus.]
Desiderius Erasmus, Adagia (III, IV, 96)
Dutch author, philosopher, & scholar (1466 - 1536)
When you first get into building software it is exciting. There is a definite thrill in gaining a new found ability to create things, watch them run, and see people start to use them. I’ve always felt that it was this ‘high’ that keeps me coming back -- again and again -- even though software development is so plagued by other annoyances.
But some days it can feel like I am dragging around a big cart behind me, filled with people kicking and screaming, while beating me on the back of the head as I am trying to focus on how to get us out of the hole and onto our destination as fast as possible. It can be a thankless job some days (when they’re not heaping false praise upon you for lesser accomplishments), but that is another story, for another day.
When you first start programming, of course you focus in on the code. It is on the small problems, which are fun and interesting. How do I manipulate this string? How to I can I call this library? How do I make this screen pretty? How do I store this data? And it is too easy in the midst of all of this to see the ‘code’ as the most important thing.
In my early years, I felt that all I needed was time. And with time I could get code, and with code I could solve any user’s problem.
But age and experience gradually creep up, and after many many experiences of seeing that the code itself didn’t save the ship, or make the user’s happy, or contribute to a career, you start to see software from a completely different perspective. It’s at that point that you awaken one day to the larger context that is swirling above the code.
There is this sudden rush as your other eye opens. You come to realize that the best algorithms, coded in the best ways, and tested with the best results, still won’t allow you to win if winning isn’t possible. You realize that any and all technologies -- no matter how slick or smooth -- are fraught with an endless series of hastily coded landmines just sitting there, waiting for you to take a fatal step. You come to realize that a poorly coded system that makes itself easy for the users has way more value then something super-complicated with buckets of functionality but is entirely cryptic, badly organized or untrustworthy. You come to understand that while the implementation is important, it’s not the ‘thing’; not the show, and not necessarily going to mean the difference between success and failure.
But most of all, you wake up to the fact that the ‘code’ itself is just a part of the puzzle, and that the algorithms, while fun to solve are the small problems, floating is a sea of large and massive ones.
I’ve watched more programmers than I care to admit retreat into the small problems and corner-cases to avoid the big ones. I’ve watched them throw all of their coding weight into extended blitzes hoping to save an already dead project. I’ve watched them burn through rolls of virtual duct tape in the faint hope that at some point they’ll get to the other side. I’ve watched them ignore the users, blame the management and generally try every trick in the book to avoid having to deal with the part of software development that they don’t like, or are afraid of. And I’ve never seen it work.
Programming is a part of software development. It is an important part and for many people it is the part that they are good at, enjoy and should focus on. But it is in no way the part that is going to carry the day. A well-built project is no less doomed than a poor one. The quality of code may become an issue at some point, particularly when it means that any new extensions are impossible to accomplish because the system has acquired way too much technical debt, but that type of premature death is just one of the many ways that our work dies, there are so many other hurdles that have to be jumped.
As is often the case, the larger issues have to be handled before the smaller ones can be successful. Architecture, design, process and consistency are necessary to keep the project sane. Empathy, politics, marketing and an understanding of the target market are necessary to make the software useful. Testing, packaging, installation and support are necessary to keep up the momentum and avoid getting bogged down by sloppy patches and dangerous work-arounds. And elegance, readability, simplicity and encapsulation are necessary to avoid painting one’s self into a corner at the later stages.
What algorithm you choose, and whether or not the you’ve applied a lot or a little micro-optimizations? These help, but at the end of the day they are just icing on the cake, or as is the case in many development shops, just icing on the floor.
[In regione caecorum rex est luscus.]
Desiderius Erasmus, Adagia (III, IV, 96)
Dutch author, philosopher, & scholar (1466 - 1536)
When you first get into building software it is exciting. There is a definite thrill in gaining a new found ability to create things, watch them run, and see people start to use them. I’ve always felt that it was this ‘high’ that keeps me coming back -- again and again -- even though software development is so plagued by other annoyances.
But some days it can feel like I am dragging around a big cart behind me, filled with people kicking and screaming, while beating me on the back of the head as I am trying to focus on how to get us out of the hole and onto our destination as fast as possible. It can be a thankless job some days (when they’re not heaping false praise upon you for lesser accomplishments), but that is another story, for another day.
When you first start programming, of course you focus in on the code. It is on the small problems, which are fun and interesting. How do I manipulate this string? How to I can I call this library? How do I make this screen pretty? How do I store this data? And it is too easy in the midst of all of this to see the ‘code’ as the most important thing.
In my early years, I felt that all I needed was time. And with time I could get code, and with code I could solve any user’s problem.
But age and experience gradually creep up, and after many many experiences of seeing that the code itself didn’t save the ship, or make the user’s happy, or contribute to a career, you start to see software from a completely different perspective. It’s at that point that you awaken one day to the larger context that is swirling above the code.
There is this sudden rush as your other eye opens. You come to realize that the best algorithms, coded in the best ways, and tested with the best results, still won’t allow you to win if winning isn’t possible. You realize that any and all technologies -- no matter how slick or smooth -- are fraught with an endless series of hastily coded landmines just sitting there, waiting for you to take a fatal step. You come to realize that a poorly coded system that makes itself easy for the users has way more value then something super-complicated with buckets of functionality but is entirely cryptic, badly organized or untrustworthy. You come to understand that while the implementation is important, it’s not the ‘thing’; not the show, and not necessarily going to mean the difference between success and failure.
But most of all, you wake up to the fact that the ‘code’ itself is just a part of the puzzle, and that the algorithms, while fun to solve are the small problems, floating is a sea of large and massive ones.
I’ve watched more programmers than I care to admit retreat into the small problems and corner-cases to avoid the big ones. I’ve watched them throw all of their coding weight into extended blitzes hoping to save an already dead project. I’ve watched them burn through rolls of virtual duct tape in the faint hope that at some point they’ll get to the other side. I’ve watched them ignore the users, blame the management and generally try every trick in the book to avoid having to deal with the part of software development that they don’t like, or are afraid of. And I’ve never seen it work.
Programming is a part of software development. It is an important part and for many people it is the part that they are good at, enjoy and should focus on. But it is in no way the part that is going to carry the day. A well-built project is no less doomed than a poor one. The quality of code may become an issue at some point, particularly when it means that any new extensions are impossible to accomplish because the system has acquired way too much technical debt, but that type of premature death is just one of the many ways that our work dies, there are so many other hurdles that have to be jumped.
As is often the case, the larger issues have to be handled before the smaller ones can be successful. Architecture, design, process and consistency are necessary to keep the project sane. Empathy, politics, marketing and an understanding of the target market are necessary to make the software useful. Testing, packaging, installation and support are necessary to keep up the momentum and avoid getting bogged down by sloppy patches and dangerous work-arounds. And elegance, readability, simplicity and encapsulation are necessary to avoid painting one’s self into a corner at the later stages.
What algorithm you choose, and whether or not the you’ve applied a lot or a little micro-optimizations? These help, but at the end of the day they are just icing on the cake, or as is the case in many development shops, just icing on the floor.
Subscribe to:
Posts (Atom)