Archive for May, 2007

Avoid Using Dynamic SQL Statements

Mind if I look through your database?Most programmers who’ve developed Web-centric database applications know about SQL injections attacks where a malicious hacker can insert commands into your dynamically built queries to retrieve passwords, infiltrate systems, drop tables or do other harm. However, desktop application developers should also be aware of the security risks and complications involved when you use dynamically built SQL statements in your applications.

The bottom line is that building SQL statements in your application code is asking for trouble. Not only does it leave you open for malicious attacks but it also makes your code harder to maintain and can cause it to behave in unexpected ways.

First, lets look at SQL Injection. If you haven’t read it already, read Stop SQL Injection Attacks Before They Stop You by Paul Litwin. He gets into some detail on how this kind of attack can happen. You may think that this is an Internet only threat but it’s not. It would be easy for a disgruntled employee or other internal hacker to gain access to data they weren’t supposed to have or even delete tables if they weren’t secured well. Remember, the “How To” for it is only a Google search away.

Secondly, if you need to make changes to the query, even a small one, this means a recompile and redeployment of your executable. Making a change to a stored procedure is much simpler and reliable. Another bonus of using a stored procedure with parameters is that you don’t have to worry about matching up or escaping embedded quotation marks. All this error prone and costly string manipulation code is handled for you. Plus, using stored procedures means that your query is optimized to run on the server, thus improving the performance of the query and your application.

Our last reason are unintended results from queries causing problems. These can also affect stored procedures. A good example would be a search criteria field. The value the user enters is used in the WHERE clause to narrow the data returned. But what if the user doesn’t enter any criteria. You may end up trying to populate a control with 1000’s of rows of data or you might have a query that runs several minutes. Another might be if a user enters a wildcard ‘%’ and uses it to gain access to records they shouldn’t have access to. To avoid these kinds of problems you should always validate user input, even if you’re loading a parameter object for a stored procedure. As Paul Litwin mentions in his article, all user input should be considered suspect and validated.

So, when you’re developing database queries for you application, think stored procedures with validated input and you’ll greatly improve the security and stability of your application on both the front and back ends.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 24th, 2007

How To Communicate With Users

Am I speaking to the party to whom I am connected?When we’re developing software we should never lose sight of the fact that it’s being developed to solve real problems and to fill needs potential users have. The end user of your program is the most important person in your project.

Often we do forget them and get hung up in writing the coolest new routine, saving a bit or processor cycle here or there, or doing other things to please ourselves. Even worse, some developers choose to punish their end users by inflicting things like forced color and font selections, forced screen sizes, non-standard Windows behaviors, crazy lockouts, and other such nonsense.

If you’re in a corporate environment, talk to your expected users regularly. Stay on top of the situation because things can change rapidly. If they work in a different location than you, plan field trips to go visit them. You can learn a lot just by observing their day-to-day process and talking to them about what would make their work easier and more efficient. You can also determine if the cool features you want to implement will annoy them greatly or be of great benefit.

If you’re doing commercial software or outsourced software it may be hard for you to talk to your anticipated users. In this case, your testing should include reality checks from people outside the project. Let them test the program from the perspective of a user. They will often notice weak areas or user interface problems that you, being close to the software, miss.

Also, don’t be afraid to give select users sneak peaks and alpha or beta test versions of your program. You have to use some care in selecting who will participate in these tests but the benefits to you and your program can be enormous. The earlier in your development process that you can deliver even a rough or incomplete version the better because user feedback can help put you on the right path to developing the best program for them.

If you’re a project leader or manager, allow your team the freedom to work with end users directly and encourage managers in sponsoring departments or companies to allow this as well. The reward will be higher quality software that users enjoy using.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter X

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment
» Chapter IX: Maintenance

Chapter X: Aftermath and Comments

Here’s what happened to our characters in the 6 to 12 months after the end of the project. I’ll also offer my final observations and comments.

Joe, our development lead, finds a new job after a couple of months out of work. He has become even more cautious and introverted and avoids taking any initiative or leadership in his work.
.
.
.
.
.
Brian, the Director of Software Development at EzSoftiMortgageCo and frequent F-bomb dropper, doesn’t get his promotion to CIO as he thought he would. This job goes to an outside hire. A few months later, he takes a CIO job with another company, much to the relief of Phil, the CEO, and the new CIO who were preparing to fire him since his bullying ways had caused considerable turnover in the software development team.
.
.
.
.
Speaking of Phil, the CEO, he sells the company to a large real estate and banking conglomerate about 9 months after the release of the failed product. He makes a multi-million dollar profit from the deal.
.
.
.
.
.
.
Most of the IT staff is laid off as being redundant a few months after the buy out, including the testing team of Pat and Tim.
.
.
.
.
.
Mary, the Director of Marketing, goes into a leadership position in the marketing department of the new company and fits right in. Phil’s recommendation seals the deal for her to make this move.

Our two sales champs, Stan and Bob, also make the move to the new company’s sales team on Phil’s recommendation.
.
.
.
As for the product that they worked so hard to develop, it is dropped from the company product line during the acquisition.

My Comments

Well, that’s our tale. It is kind of a worse case scenario but it isn’t that uncommon of an experience for many who work developing software. Many parts of it probably felt like, “Been there, done that” to you. Let’s look at a few aspects of the story.

Joe, what can we learn from him? His situation comes about, in part, because he isn’t a good communicator and that he doesn’t push back enough on unreasonable demands and bullying until it’s too late. This is unfortunately a problem for many skilled software developers when faced with people with more forceful personalities, like just about everyone else in our story. Learning how to push back and deal with office politics is an important skill for all programmers to learn. Learning how to deal with a bully of a manager is also important.

Brian is an example of a manager who uses yelling, subterfuge, and bullying to control people under him. He’s perhaps taken to extreme in this story since he is an amalgam of the bad aspects of about 8 or so managers I’ve either worked for or people I know have worked for. However, managers that toxic do exist out there so you, as a software developer, have to be prepared to deal with these walking, talking, versions of Bill Lumburgh or Dilbert’s boss.

In the testing team of Pat and Tim, we see another negative aspect in software development, the unintentional and intentional sabotage of fellow employees who’re considered weak or rivals. In a toxic corporate environment, such people can make your troubles worse if you let them.

The rest of the characters are pretty typical corporate types you’re likely to encounter in any company, the demanding marketing manager, hard charging but somewhat clueless salespersons, and out-of-touch executive management. Knowing how to deal with them is important too.

Process-wise, the company had several problems. Most of these center around poor communication. For example, the problems Joe had with scheduling meetings with Mary. Ideally, communication would have been open enough to overcome the design problems a lot earlier. The less said about Brian’s communication technique the better, it simply isn’t the way an effective manager communicates with their subordinates.

Another problem you might have noticed was that testing did not get involved early in project but at the very end. One of faults I see in the whole 7 steps paradigm is that testing comes after coding. In practice, I’ve found incremental testing of incremental releases as coding continues to be more effective in weeding out bugs and producing a better end product.

Your Comments

If you have any comments you would like to make on this story, please make them here or use the contact me menu button to send me an email. Thanks for reading and I hope you enjoyed the story.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

1 comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter IX

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing
» Chapter VIII: Deployment

Chapter IX: Maintenance

This step is concerned with maintaining the existing program by fixing any bugs and enhancing the software. In our case, the misery continues.

Joe is hardly surprised about a week after the product ships to get a call to report immediately to HR when he arrives one morning. It seems that the company has instituted a new program called ‘forced ranking‘ and it seems that Brian has rated him as being a ‘C’ player. He signs a few documents and is escorted out the door by a security guard. His belongings from his desk are shipped to him a week later with several things missing.

Brian reinforces the point with all of his employees in a meeting by telling them, “If you’re a [explicative]-up like Joe you’ll be gone too!” The already low department morale sinks lower.

Hoping to address the perceived weaknesses in the original release, Mary and Brian work up a spec for a 1.1 release. Unfortunately, all of the contractors who worked on the project have left and the two remaining junior programmers who were on the project are working feverishly on the significant problems in the company’s core product. No one on the software development team wants to take on a ‘cursed’ project and find ways to avoid taking ownership of it. The enhancements are shelved and the product languishes and becomes even more unpopular in the company and with customers.

It doesn’t look like the program has much of a future. Next we’ll take a look a few months down the road and see what’s happened and I’ll offer my closing comments in Chapter X: Aftermath and Comments.

Following Chapters

» Chapter X: Aftermath and Comments

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 23rd, 2007

The 7 Steps of Software Development Case Study - Chapter VIII

Previous Chapters

» Chapter I: Introduction
» Chapter II: Cast of Characters
» Chapter III: Preliminary Investigation and Analysis
» Chapter IV: Specification and Requirement Analysis
» Chapter V: Design
» Chapter VI: Coding
» Chapter VII: Testing

Chapter VIII: Deployment

Now it’s time for the program to leave the nest and find its place in the world.

Bob, the National Sales Manager, has a large nationwide client that wants the new product “NOW!” even though it’s still in testing and not due for full release for another 10-14 days. Since the commission from this sale will be huge, he talks to his boss, Stan, into getting the new product to them ahead of time. Stan says “Do what you have to do to make the sale.” Bob goes to his sports betting pal, Tim in QA, and takes an install CD from the test lab and delivers it to his very important customer.

However, Joe doesn’t know this has happened until a rep in the tech support group calls him and asks why the new product won’t install on the customer’s system. Joe says that the product shouldn’t even be shipping yet and calls the customer himself and discovers what happened. It turns out that Bob gave the customer the original defective test CD. A good replacement is sent but the customer has cooled on the product and they don’t place as big an order as had been anticipated. Bob blames IT in general and Joe specifically for the canceled orders.

Finally, the actual product is released and it gets a rather tepid response in the marketplace and from within the company. Industry blogs and trade magazines call it a weak “me too” product. Mary hates it and says that it wasn’t what she had specified. Bob warns his salespeople to be careful selling it until all of the bugs are worked if they want to keep their customers happy. Stan and Phil question Brian on why the project went so badly and why the upgrade to the key company product, Joe’s previous product, is having so many problems. Brian makes it clear what the connection is between the two (Joe) and promises to take care of him and any other non-productive and incompetent people in his department.

At last, it’s time for the program to go into maintenance mode and for the department to do a post-mortum on how well the project went and to make any corrections. Can you guess who will get corrected? Read about it in Chapter IX: Maintenance.

Following Chapters

» Chapter IX: Maintenance
» Chapter X: Aftermath and Comments

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Add comment May 23rd, 2007

Next Posts Previous Posts


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives