Okay, while I'm not usually that angsty, the whole Linux vs. Windows thing does get me riled up easily. Anyway, I figured I should balance it out with a much more calm and serene post.
So, you are a software developer? Or you think you are anyway. Software developers think they know everything. That is good in some ways, highly annoying in others. However, lately I have noticed that many foreign programmers will come into mailing lists that I moderate (e.g. http://groups.yahoo.com/group/c-prog) and they will say, "I have a doubt" as the subject line. Then they will doubt again in the body. Several times. It is okay to have the occassional doubt, but doubting every other sentence is rediculous...especially where people post about code they could have run through a compiler asking about their doubts compiling it. If we lived back in 1960-something where compiling a program took hours or a day and had to be scheduled I could understand people doubting a compiler would compile code. Punchcard machines took forever. So, every single compilation counted. Nowadays, it seems to me that it is awfully lazy to not compile code and simply e-mail 3000 people to do it for you.
So, my first tip is to compile your own code.
The next thing I see a lot of software developers wanting is someone else to do their own code writing for them. Software developers who want this should look in the yellow pages under "consultants" and be prepared to shell out $200/hour. Personally, I strongly believe in the concept of code ownership. When I work on something in code, I like to stamp it with my name, my style, pretty much everything that signifies that I have been there. The code ends up being well-formatted, with good comments, and bugs ironed out. I own the code. Open Source, bless its soul, takes code ownership away from the developer. No longer can an individual developer say, "Hey, look! I did that." Only those who start any given project are remembered briefly in the project's history. Anyway, I digress. Code ownership is very important - it gives warm fuzzy feelings to developers to stay on task and get the job done right.
So, as a long-time developer to developers, you own the code you write so, "do your own homework." Well, the company you work for owns the code too, but make sure they give you breathing room to be able to say, "Hey, look! I did that." People will be impressed. Also, be assertive about pretty much everything except that which you truly are not sure of. Usually, if you just sit down with paper and pencil and scratch out how to go about solving the problem, it will become clear as to how to solve it.
Don't lose the end-user. Software developers have this amazing knack for getting so lost in code, they lose sight of the end-user. As with my previous discussion, Linux has proven this point to a fine art of what happens when you do lose track of a simple thing called usability testing. Simply writing code is not enough, you have to do lots of other things - like sit down with a user with paper and pencil and simply watch them use the software. Silently. Developers have this knack for ruining usability tests - they want to preempt the user's thoughts by talking them through how to do something. Don't. Just sit there watching and jotting notes. The user will probably find all of the bugs you missed while just sitting there. Of course, if they can't figure out the software, then you have a bigger problem than them finding your bugs...either they aren't in the target market you thought or your software isn't usable. They will let you know if it is the latter.
Don't believe everything being told to you in MSDN Magazine or Linux Journal or whatever on application security. 90% of all bugs being found and exploited in software today are buffer overrun situations because people use things like gets(). Every coder makes mistakes (even Linux developers), but a buffer overflow should be near impossible to create if the developer knows how to write correct code. What every developer should have in their toolkit is a library of "safe" functions and methods that they can call that are known to be bug free. When user input is being handled, these "safe" functions should be used to handle that input. Only in extremely rare cases where it becomes obvious that performance is being hindered by the "safe" functions that the developer is using should alternative routes be considered. In this case, management makes the call, not the developer to go to an unsafe method of doing the same thing. The code is then peer-reviewed for problems afterwards. By using "safe" functions/methods/classes, a huge number of bugs are overcome.
So, use "safe" functions, methods, and classes. If a function, method, or class is being considered for addition to the list, it needs to be peer-reviewed and cross-checked with everyone else.
Common libraries. Developers rarely understand the importance of common libraries. I have seen in the open source arena, the same code duplicated across thousands of projects because no one is willing to put that code into a common library and enforce it. The same thing happens in Windows development on a smaller scale just because most Windows development tends to involve API calls. In both cases, neither side understands what a common library is for. Common libraries should provide wrapper functionality around OS-level APIs and be a place for "safe" functions, methods, and classes. I've already discussed the latter, but the former is something most people don't think about until they go and try to port to Linux. If you are a Windows or Linux developer, you are going to be smacking your head and saying at the end of this, "Duh, why didn't I think of that?" Basically, after years of experience, if I plan on porting an application from Windows to Linux, I rely heavily on my core library to interface with the OS and then I just have to worry about higher-level stuff at the application level. So, at the application level, everything is just putting together a pipeline for data. The library underneath builds the pieces of the pipeline. So, you may ask, "Well, if you are still calling APIs, how does that make it better?" I'm only calling an API one time. Ever. Porting is made easy. Simply write a lightweight wrapper for Linux and, bam, I've got pthreads and socket connections that look like Windows threads and sockets to the library. To the application, nothing appears to have changed. Just recompile and run.
Finally, all developers should be checking out this blog. Frequently. It has tips and tricks. It has nifty things. Best of all, I can help you keep focused.
When a software product is all said and done, independent developers still need to market their product. That is where I can help as well. My reviews of software are the blatant truths about it - none of the gibberish Tucows hands out. Tucows 5 cows awards are meaningless - it means you have good documentation, not necessarily a good application. If you want, I can help you put together a comprehensive package that will have everything you need to know and do for $350 to make the product successful. That includes my price for writing a review. Is the extra $100 worth it? If you aren't spending at least $10,000 on any given piece of commercial software to get it out there, you aren't serious about the software you write - go get a day job. So, $350 to get the information you need to keep your overall costs down along with a sound review of your software is a great way to kick it off. If I'm impressed, and that's tough to do, it just might get reviewed here.
So, you are a software developer? Or you think you are anyway. Software developers think they know everything. That is good in some ways, highly annoying in others. However, lately I have noticed that many foreign programmers will come into mailing lists that I moderate (e.g. http://groups.yahoo.com/group/c-prog) and they will say, "I have a doubt" as the subject line. Then they will doubt again in the body. Several times. It is okay to have the occassional doubt, but doubting every other sentence is rediculous...especially where people post about code they could have run through a compiler asking about their doubts compiling it. If we lived back in 1960-something where compiling a program took hours or a day and had to be scheduled I could understand people doubting a compiler would compile code. Punchcard machines took forever. So, every single compilation counted. Nowadays, it seems to me that it is awfully lazy to not compile code and simply e-mail 3000 people to do it for you.
So, my first tip is to compile your own code.
The next thing I see a lot of software developers wanting is someone else to do their own code writing for them. Software developers who want this should look in the yellow pages under "consultants" and be prepared to shell out $200/hour. Personally, I strongly believe in the concept of code ownership. When I work on something in code, I like to stamp it with my name, my style, pretty much everything that signifies that I have been there. The code ends up being well-formatted, with good comments, and bugs ironed out. I own the code. Open Source, bless its soul, takes code ownership away from the developer. No longer can an individual developer say, "Hey, look! I did that." Only those who start any given project are remembered briefly in the project's history. Anyway, I digress. Code ownership is very important - it gives warm fuzzy feelings to developers to stay on task and get the job done right.
So, as a long-time developer to developers, you own the code you write so, "do your own homework." Well, the company you work for owns the code too, but make sure they give you breathing room to be able to say, "Hey, look! I did that." People will be impressed. Also, be assertive about pretty much everything except that which you truly are not sure of. Usually, if you just sit down with paper and pencil and scratch out how to go about solving the problem, it will become clear as to how to solve it.
Don't lose the end-user. Software developers have this amazing knack for getting so lost in code, they lose sight of the end-user. As with my previous discussion, Linux has proven this point to a fine art of what happens when you do lose track of a simple thing called usability testing. Simply writing code is not enough, you have to do lots of other things - like sit down with a user with paper and pencil and simply watch them use the software. Silently. Developers have this knack for ruining usability tests - they want to preempt the user's thoughts by talking them through how to do something. Don't. Just sit there watching and jotting notes. The user will probably find all of the bugs you missed while just sitting there. Of course, if they can't figure out the software, then you have a bigger problem than them finding your bugs...either they aren't in the target market you thought or your software isn't usable. They will let you know if it is the latter.
Don't believe everything being told to you in MSDN Magazine or Linux Journal or whatever on application security. 90% of all bugs being found and exploited in software today are buffer overrun situations because people use things like gets(). Every coder makes mistakes (even Linux developers), but a buffer overflow should be near impossible to create if the developer knows how to write correct code. What every developer should have in their toolkit is a library of "safe" functions and methods that they can call that are known to be bug free. When user input is being handled, these "safe" functions should be used to handle that input. Only in extremely rare cases where it becomes obvious that performance is being hindered by the "safe" functions that the developer is using should alternative routes be considered. In this case, management makes the call, not the developer to go to an unsafe method of doing the same thing. The code is then peer-reviewed for problems afterwards. By using "safe" functions/methods/classes, a huge number of bugs are overcome.
So, use "safe" functions, methods, and classes. If a function, method, or class is being considered for addition to the list, it needs to be peer-reviewed and cross-checked with everyone else.
Common libraries. Developers rarely understand the importance of common libraries. I have seen in the open source arena, the same code duplicated across thousands of projects because no one is willing to put that code into a common library and enforce it. The same thing happens in Windows development on a smaller scale just because most Windows development tends to involve API calls. In both cases, neither side understands what a common library is for. Common libraries should provide wrapper functionality around OS-level APIs and be a place for "safe" functions, methods, and classes. I've already discussed the latter, but the former is something most people don't think about until they go and try to port to Linux. If you are a Windows or Linux developer, you are going to be smacking your head and saying at the end of this, "Duh, why didn't I think of that?" Basically, after years of experience, if I plan on porting an application from Windows to Linux, I rely heavily on my core library to interface with the OS and then I just have to worry about higher-level stuff at the application level. So, at the application level, everything is just putting together a pipeline for data. The library underneath builds the pieces of the pipeline. So, you may ask, "Well, if you are still calling APIs, how does that make it better?" I'm only calling an API one time. Ever. Porting is made easy. Simply write a lightweight wrapper for Linux and, bam, I've got pthreads and socket connections that look like Windows threads and sockets to the library. To the application, nothing appears to have changed. Just recompile and run.
Finally, all developers should be checking out this blog. Frequently. It has tips and tricks. It has nifty things. Best of all, I can help you keep focused.
When a software product is all said and done, independent developers still need to market their product. That is where I can help as well. My reviews of software are the blatant truths about it - none of the gibberish Tucows hands out. Tucows 5 cows awards are meaningless - it means you have good documentation, not necessarily a good application. If you want, I can help you put together a comprehensive package that will have everything you need to know and do for $350 to make the product successful. That includes my price for writing a review. Is the extra $100 worth it? If you aren't spending at least $10,000 on any given piece of commercial software to get it out there, you aren't serious about the software you write - go get a day job. So, $350 to get the information you need to keep your overall costs down along with a sound review of your software is a great way to kick it off. If I'm impressed, and that's tough to do, it just might get reviewed here.
Comments
Post a Comment