Tag: worst practices


Mar
2014

Requirements Gathering: set up to fail

categories: Developer Hell

Without project requirements gathering, a project is nothing. One failure point is letting the wrong people gather the requirements.

Image courtesy Rebecca Dominguez (CC BY-NC-SA 2.0)

There are basically two types of requirements for an application project: the functional/feature-set and the technical.

Traffic ConePitfall: There must be at least one cycle of comparing Functional to Technical requirements to ensure they sync up, followed by adjustments to both (as necessary).

Functional

This answers the two questions:

  1. What will this application do?
  2. How will the user interact with the application to get #1?
function requirements gathering can specify oven-baked fries
Oven baked fries (source: Wikipedia)

If you want your application to feed the user by ordering from Fries-2-Go™, the 24-hour french-fry delivery service (fries in 27.5 minutes or you supersize for free!), that is #1. If  you say that the user will push the Big Red Button on the app, then say what flavor fries they want (Creamy Chicken Velouté, Herb Hollandaise, or Buttery Béchamel), that is #2.

Note that we didn’t say HOW this magic happens. That is not the purview of the Functional Requirements.

Traffic ConePitfall 1: the stakeholders (especially people who are representative of those who will use the app) MUST participate when crafting the requirements, especially any workflow.

Traffic ConePitfall 2: failing to involve an experienced technical architect during this phase may result in defining requirements that are not technically feasible, craft a clumsy/unwieldy workflow, or miss borrowing from solutions in similar applications.

Technical

These requirements are concerned with the plumbing, the hidden part of the iceberg and the underground kingdom of the Troll People. Functional requirements—from a high level—are absolutely required (see what I did?) to be defined before the technical requirements are attempted.

Traffic ConePitfall: any attempt by non-technical folks to attempt to work on these will result in flawed implementation, busted schedule, cost overruns and lowered team morale (lowered productivity).

Failure Examples

A high-level manager defined functional requirements with no input from field staff or technical architects. She then defined technical requirements based upon an internal standards white-paper, but without the understanding necessary to apply the standards to this project.

The technical staff was brought in at the last minute and told to review the requirements quickly so that work could begin. Immediately, the staff noticed several major flaws. For example, one of the functional requirements violated app store constraints, which would prevent the app from ever being accepted by the app store. In addition, the requirement was completely unnecessary, as there were external apps that provided the same features.

The manager (perhaps to save face) ordered the project proceed with the original functional requirements intact. This resulted in a product that cost more than necessary, it could not be distributed via well-known app stores, and it contained useless and confusing functionality.

Enhanced by Zemanta

Jan
2013

Don’t hate your users

categories: web development

If you want to enable your users to do something, such as create an account on your system, DO NOT MAKE IT IMPOSSIBLY HARD.

Case in point:

This image will make you cry
Go ahead and register, I dare you

If algebra is too hard, just refresh and you’ll see something else.

Another scary image
I laugh at your feeble Calculus skills!

Woah, better refresh.

You can't escape the Maths
Make your time

You know what this does? It not only keeps out any bots, but turns a normal human into something else:

rageface
Apoplectic: overcome with anger; extremely indignant.

With a zillion other websites out there, are you sure yours is compelling enough or contains such rare information that people will jump the gorge to get to it?

https://www.youtube-nocookie.com/embed/P7vte1epVpE?rel=0

 


Jan
2013

How to ask for help the wrong way

categories: Skills

When submitting  bug reports, it is a good idea to

A room full of computers all showing the BSOD

  1. Realize that you’re asking for help from people who (usually) have day jobs, and
  2. Expend at least some amount of effort to show you’re not expecting someone else to do all the work.

With that in mind, let me introduce to you the Best Bug Report Comment, Ever†

First the bug report:

[snip]

I don’t have the exact errors to post because I deleted my compile log, but they are the same errors you get if you don’t have the bzip2 development libraries installed, which of course I do in /www

[snip]

Then someone helpful asks for more information.

Please recompile so that you can tell us te exact errors.

Derick

And then, GOLD:

The php developer who added/maintains bzip2 support will know what I am talking about. I am not going to compile when I know this! It would be a waste of my time.

Wow.

Now, not to worry; a few minutes later the submitter saw the error of his ways, compiled his code, posted the exact error message and got help.

Learning how to ask questions is a skill. Mastering this skill can only help, because everyone (even the Super-cool techno guru) has to ask for help at some point, so why not be as effective as possible?

† Until I find another one. That place is GOLD!

Enhanced by Zemanta

Sep
2012

The Importance of Not “Designing” your own Security

categories: web development

Recently, at a client, I had the opportunity to review their security implementation on their website. I realized that it is very important to never try to design one’s own security, because of the Dunning Kruger effect. In a nutshell, folks who don’t know very much about security think they know “enough,” and folks who are very knowledgable (e.g., Bruce Schneier) realize they don’t know all that much.

So what does this mean? It means simply this:

If you design your own security system, you’re going to get it wrong.

English: A Master padlock with "r00t"...
(Photo credit: Wikipedia)

Here are some examples of how to get things wrong.

Storing passwords in plaintext so you can send the person the password if they forget.
When (not if) someone breaks into your database, they instantly own every single account. They can log in, view your user’s details and change them. Since most people reuse the same password for multiple systems, the attacker can try those passwords on other popular services, such as Facebook, GMail, LinkedIn, Twitter, etc.
Relying on application-level security to protect your data.
This is dangerous because it is hard to ensure 100% coverage. EVERY access point—of many—to your data must be secure. Failing to cover one point leaves the system wide open. A better solution is to apply security at the data-store level. Typically, this is done using triggers and stored procedures. Your RDBMS doesn’t support those (or weakly supports them)? Find another RDBMS.
Using the same salt for every password in the system.
You don’t understand what salts are for and how to use them properly.
Requiring “complex” (a number, upper- and lower-case letters and symbols but not very long) passwords.
Nope. Ineffective.
Relying on Two-Factor Authentication.
For now it is working, somewhat, but crackers are rapidly finding ways to circumvent this technique.
Relying on a “security question” in case the person forgets his/her password.
Oh, you’ll love this. You’re creating a weak password as a backup to a (hopefully) strong password. Fail.
Assuming by keeping the details of your implementation secret, you will be secure.
This is dangerous because you think you’re secure. In fact, you are less secure. Kerckhoffs’s Principle is always a good starting point for security implementation: if an attacker could see all of my code and had a copy of my database, could she/he break into my system?

Getting it right

The first step is admitting that you don’t know what you’re doing.

Now go find someone who does: there are plenty of security libraries out there for every language. Find one that is mature and widely used and implement it. Keep up to date on the library’s mailing list so you will receive alerts, and update whenever there’s a new version.

Security is hard to do. It is extremely hard to do correctly. Don’t fall into the trap of thinking you can get it right without years and years of study and experience.

Related articles
Enhanced by Zemanta