Charles Rowe dot com

I have been meaning to write a web security post and Ilya Grigorik has inspired me with the post “Web Security With Ingress Filtering”. Ilya lists some solid points for protecting your web application. Here are some fundamental points that continue to crop up all the time. If you know them: Congratulations, you are ahead of the game.

(more…)

The times when you shouldn’t track bugs formally are so few that there shouldn’t even be a debate on the topic. As developers, the tracking of bugs is one of those things that you need to encourage whole heartedly. There are more uses for bug tracking than you would think. Keeping bug tracking as a glorified to-do list puts you at a loss. I have 8 good reasons why everyone should have some sort of tracking system.

(more…)

The Codist has an article today entitled, “So You Want To Become A Programmer“.
The post has 6 solid entries for getting a person imbued in the programming culture, and landing the first job. If these sort of tips interest you, I strongly suggest you give it a read. I humbly offer my own additions to the list:

7) Code cleanly
This could be an amendment to #4 . Writing clean code can give you a distinct edge if you are lacking experience.
There are so many people that write spaghetti code with the one letter variables, and 100+ line functions who brute force their way into the profession through sheer problem solving ability and force of will. When you apply for an entry level position, you are often applying for the ability to mentor with a senior developer, or a team of developers. They would rather have a “clean slate” with no bad habits, than a hot shot problem solver who writes in their own dialect.

8) Learn development methodologies
This one is two fold:

1. Even if you are a solo developer, you are never coding alone. Part of being a professional programmer is insuring that when you get hit by a bus, the application doesn’t go with you. You need to learn what is expected of a good application, and what your future project leads or maintainers would like to see.
2. Learning development methodologies is also a good idea because it will give you a better idea how to interact with a team of developers. Lone coders are a dime a dozen. If you know how to play nicely in the sandbox, you will be more attractive to potential employers. A team can’t rearrange itself to fit your quirks. Showing that you understand when and how to communicate, and an idea of the many phases of development will lower any risk associated with your employment.

9) Learn to love over-time.
If you program, you are going to be lucky to have a 40 hour week. Yet, You are probably going to be paid for 40 hours of work as a salaried employee. You need to come to grips with that fact. Few people -enjoy- working and not getting paid for it, but is going to happen. On top of that, you have selected one of the most fluctuating fields out there. It is on your time, and your dime to keep pace with emerging technologies. This is one aspect that separates a good programmer from a great programmer.

10) Get the job done
The previous points have been about doing your job well. This point is about WHEN you do your job.
All businesses and project owners operate under deadline. If you accept a project with a deadline, you need to follow through. Even if you accepted something with a ludicrous date, the deed is already done. This point ties to #9.When you accept any deadline, it is your responsibility to see it through (regardless of the time it takes). When you follow through on deadlines with clean code, you increase your trustworthiness, your reputation, and your value as an employee. You want to be the goto person and in demand. If you consistently getting low balled with deadlines, you need to assess your situation:

1. Are you estimating your due dates correctly? Do you have a good methodology for estimating man hours?
2. Have you educated your project owner about cutting corners? Have you given real world examples of how deviating from procedures can impact the bottom line?
3. If you feel you have sufficiently addressed the first two items, it is not out of the realm of possibility that you are being taken advantage of. At least you get a clear signal that the current position is not a good fit.

As an essential requirement to your web development project, the business requirements document acts as a communication conduit between the developers and the project owner (customer). A well written BRD can protect the developers and the customers from miscommunication, inefficiency, and missed deadlines.

Put Simply: the BRD is a carefully worded, non-technical document that lists the features, requirements, and basic operations of an application. It is important to write the document so that your customer can clearly understand it. If applicable, use any of the customer’s specialized terminology to demonstrate clear lines of communication and an understanding of their needs.

If you have yet to use a BRD the important thing is to do your research and get your customer’s requirements on paper. The BRD is your shield against the consistent redesign of an application while it is in the process of development (known as feature creep). The consequences of consistent unplanned redesign are missed deadlines or budgets, and in the worst case, project failure.

Remember, the developer’s job is to serve the customer. The customer has the right, and sometimes the need, to change the scope of the project by modifying their requirements. This is fine. Nothing the developer does can ever be set in stone. If the customer is willing to pay the cost of a scope change, then it is something that has to be done. The BRD is not a wall intended to separate customer from developer, It is a means of bringing the two parties closer together so that they can accomplish the project as a team.

You will often have to go through many versions of a BRD until you are ready for development. Usually there are areas which are unclear and will require prototypes or interviews with a subject matter expert. This is perfectly normal. The goal of the business requirements document is to act as the back bone of the project. Make it clear to the customer that the business requirements document drives the project plan, which in turn sets the deadlines and cost of the project. When the customer understands that a modification of the business plan could push the project boundaries, then the developer has the best chance of avoiding impossible deadlines.

Click here for a rough example of a Business Requirements Document

For those who have never seen a BRD, the above document is an extremely basic example to give you a rough idea. Numbering a BRD in outline format is typical for large Business requirements. When making revisions, or using the business requirements for acceptance tests. It is much easier to say “item 8.4.2.1 needs modification” than trying to explain that a modification is required on pg. 9, 15^th line.