BOOK: Economics for Dummies

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/book_economics_for_dummies.htm]

 

I have never met a developer who said they had enough time to "properly" finish their project. Sure, everyone starts the project with dreams of how this will be momentous - somehow the stepping stone to curing cancer and world hunger - but then reality sinks in and the team scrambles to make the best of their limited time.

And that's where economics, the science of how people deal with scarcity, comes in. I had to take a micro and macro Econ course back in college for my engineering degree, but back then it was just an 8:00am commitment. When I was reading Joel on Software's blog, he picked my interest with economics again with his talk of compliments and supplements, vendor lock in, the chicken & egg problem, etc... So, I got a copy of "Economics for Dummies". I saw it as Part II of The Complete MBA for Dummies.

Living up to the "Dummies" genre, it was an easy read. The concepts of utility, marginal revenue, return on investment (ROI), consumer surplus, diminishing returns, and supply and demand are good things for any developer to know. Much of this may seem like common sense in today's world, but a book helps one to articulate what their head thinks is common but they can't find the words for.

Besides assisting with prioritizing features and making calculated risks, it helps a technical person continually appreciate the business side of things.

 

Technology is the engine, but the Business is the steering wheel

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/technology_is_the_engine_but_the_business_is_the_steering_w.htm]

I like analogies. Initially, I was thinking of polar coordinates, where technology is the magnitude, but the Business is the direction - however that sounded too techy.

The idea is that you can have the most powerful technology in the world, but if it's not focused in a profitable direction, your business (which pays for the technology) will never get to the right place.

You need both tech and business, else you plateau very quickly. Without business understanding, the technologists can build amazing things - that no one wants. That's fine for hobbyists and CS college students, but not sustainable for companies.

Without technical understanding, the business people can dream of profitable ideas - that no one can build.

What is a number?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_is_a_number.htm]

Having an application collect a number from the user seems simple. Just whip out a textbox, maybe add an "integer validator", and ta da! Sounds great, but endless things can go wrong (things can always go wrong, like with states, zip codes, or even labels). I'm certainly not saying that every textbox in every line of business app should handle all of this, but here are some things to be aware of:

• Do you allow for special characters, like dollar signs "$", percents "%", or financial negative numbers "( )"? [Seriously, try formatting a negative dollar amount in Excel]
• Do you allow commas?
• Do you allow decimals?
• Do you handle globalization? Some countries use the "," for a decimal point, and the "." for a comma (the inverse of what America does).
• Do you allow both "-" (for negative) and "+" for positive, or is the "+" just implied by default?
• Do you allow pre and post zeros: "001.00". Keep in mind that the zeros on the left are mathematically redundant, but the zeros on the right may count as "significant digits", and denote a degree of precision. The extra zeros in "1.25000" implies a much more precise number than just "1.25". However, most numeric types in .programming languages will truncate the trailing zeros.
• Do you allow exponents for large numbers, like "1E+12" (that's 1 with 12 zeros after it: "1,000,000,000,000")?
• Do you allow abbreviations, like "10M" for "10,000,000"? (FWIW, I'm not sure of any app that actually does this.)
• Do you have a clearly defined range? For example, a smallint (Int16) stores much smaller numbers than a long (Int64). Most business values can be stored with a double. However, if you're extending a legacy system that only provides a byte or smallint, but it expects occasionally huge values, then you could get into trouble.
• Is your validation lenient? For example, if the user enters multiple commas "23,5,6" - do you simply remove all the commas and have "2346", or is that an error?
• How do you handle nulls? Do you use a sentinel value (like Int32.MinValue), or use the new Nullable data types, or something else? If using a nullable value, does it "convert up" - i.e. Int32.MinValue is null if the type if Int32, but it would be a valid non-null value if the type was Int64. If you have multiple systems reading the same value, and one system uses Int32, and the other uses Int64, will your system still work (this can happen when you start doing things like letting the user dynamically create their own pages or reports).
• Not to be smart-alecky about it, but I'd just assume that unless otherwise told, this accepts base-10 inputs. I.e. "A5" and "FF" are invalid values - although there may be apps where that is legit (like specify a color in HTML for some blog or content-management software).

Also, does your system handle transformations? That's where you collect the input, store the raw data as something else, and display a newly formatted value. Perhaps the most common example is with percents. A user may type "50" into a textbox (with the "%" in the label next to it), you may save it in the database as "0.5", and you may format it back as "50%" on a report. Or a user may enter "+0" in a textbox, and you simple store and display it as "0".

So, some numerical inputs to test with (besides the obvious invalid numeric inputs, like "xyz") :

• -23,456.000
• -23.456,00    //Globalization
• $45,345.00
• $(4.00)
• The max/min values for each of the numeric types.
• Fill the entire textbox with 9's.
• 000000000
• +23
• 23     //try the simple case
• -0
• +0
• 1.25E+12
• 1.25 E + 12    //note the spaces

The things to look for are (1) will these prompt validation messages, (2) how will each value be stored in the database, and (3) how will the value be re-formatted when it's displayed.

Perhaps the best standard is to see how Excel handles it, as Excel is probably the most famous application in the world that handles numbers.

How Zip Codes can get complicated

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/how_zip_codes_can_get_complicated.htm]

I mentioned in a previous post that while states (in an address) seem simple - indeed most developers have made a dropdown to "pick your state" - in legacy apps they can quickly get complicated. Same thing applies to zip codes. It sounds like a secondary afterthought - "Oh, just add a field to the application so we can store numbers like 20500." However, it can quickly snowball:

• Do you store the 4 digits at the end, like "20500-0003".
• If you remove the spaces and dashes, you're left with just numbers - which seems easier to store and search on. So do you store it as an integer (205000003)? This might work if you're only looking at cities in the midwest or west coast, but some east coast states use zip codes that start with a "0", which would get truncated if stored as a number. Personally, I prefer to store them as a varchar, and then have a UI validation (for new) and backend scrubbing process (for existing) to standardize the format in the database.
• Do you enforce valid zip codes only? Not every 9-digit combination of numbers is a valid zip code - i.e. there are not 1 trillion distinct codes that actually are used.
• Many applications assume that one zip code belongs to one state - but there are scenarios where a single zip code is shared by multiple states (seriously).
• Do you allow your zip code field to store international postal codes? Many US applications start off small, and only worry about the US market. Then some business sponsor says "we're missing out on the Country XYZ market, quick, update the app to handle foreign cities". This often causes changes to an address screen, and the quickest way to change it may be providing an "Out-Of-Country" option for the state dropdown, and allow the zip code to store international postal codes.
• And do you handle all this in the UI with a rich control, or just use a "flexible" 10-character textbox?

What can go wrong with changing a text label?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_can_go_wrong_with_changing_a_text_label.htm]

What could go wrong if the business sponsor just wants to change some little text on a label? It sounds like the simplest thing. And while it should be a simple change, it can sometimes get complicated (i.e. expensive).

• Globalization - If the app needs to support multiple languages, then the new text needs to be translated into all those target languages.
• Special Characters - The new text could support special characters that need to be encoded (like & or < or >).
• Non-supported characters - The new label introduces a special character not in the original character set (such as some foreign language), and the application only supports basic ASCII.
• Changes flow layout - The new label is longer or shorter, which changes the flow layout. For example, the new text is long enough to force wrapping (which pushes a row to high) or it doesn't wrap so it pushes a column to wide.
• It's an image - Perhaps the label is actually an image (for fancier looking designs), not just text.
• Text is not determined in the presentation layer - Perhaps the label is set dynamically through code or configs, such as pulling from a meta-data dictionary.
• Text was dynamically built - Perhaps the label was dynamically concatenated via some existing logic (for example, it pluralizes the text if some count > 1), so you're not just setting a literal string anymore.
• You don't own the text -  Perhaps the label comes from an embedded, third-party component that you don't own and cannot easily change.
• The label appears in multiple places - Perhaps the label appears in multiple places, and so all places need to be updated. For example, it also appears in a UI Report writer where you select the UI-friendly name instead of the database schema column/table.
• (Bad design) - other code depends on the label text - Perhaps the application has bad design, and there's actually code that reads the value of the label to determine if it should do some other action. For example, if the label contains some word X, then hide section Y (as opposed to whatever method sets label to word X also hides section Y).
• New font -  Perhaps the new text actually introduces a new font that isn't available on the client (this isn't merely changing text, but it's associated with that kind of request).

The address's State field may contain more than just the 50 states

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/the_addresss_state_field_may_contain_more_than_just_the_50_.htm]

Most business applications eventually ask the user to enter an address. There's the user's address, shipping address, their company's address, maybe an emergency contact's address, address history, travel-related addresses, financial addresses, etc... Most addresses have a city, state, and zip. While city and zip seem simple (more on that later), many devs initially expect the "State" field to be simple - perhaps a two-character column that can store the 50 US states. However, it can quickly balloon to something much more complicated (especially if you're troubleshooting some legacy app). Besides the standard states, it could contain:

Military codes (reference)

Armed Forces Africa	AE
Armed Forces Americas (except Canada)	AA
Armed Forces Canada	AE
Armed Forces Europe	AE
Armed Forces Middle East	AE
Armed Forces Pacific	AP

US Possessions (reference)

AMERICAN SAMOA	AS
DISTRICT OF COLUMBIA	DC
FEDERATED STATES OF MICRONESIA	FM
GUAM	GU
MARSHALL ISLANDS	MH
NORTHERN MARIANA ISLANDS	MP
PALAU	PW
PUERTO RICO	PR
VIRGIN ISLANDS	VI

Perhaps Canadian provinces? (reference)

Alberta	AB
British Columbia	BC
Manitoba	MB
New Brunswick	NB
Newfoundland and Labrador	NL
Northwest Territories	NT
Nova Scotia	NS
Nunavut	NU
Ontario	ON
Prince Edward Island	PE
Quebec	QC
Saskatchewan	SK
Yukon	YT

Generic codes to indicate international use?

Foreign Country	FC
Out of Country	OC
Not Applicable	NA

Or, specific applications may try their own proprietary international mapping, like "RS" = Russia. This might work if you're only doing business with a handful of countries, but it doesn't scale well to the 200+ (?) existing other countries (i.e. I would not recommend this. Use a "Country" field instead is feasible).

Special codes to indicate an unknown, or empty state?

XX

*

..

?

Perhaps, for some reason, the application developer isn't storing just 2-char codes, but rather integer ids that map to another "States" table, so you see numbers like "32" instead of "NY" ("New York")?

Or, even worse, they're shoving non-state related information into the state column as a hack that "made something else easier".

How many distinct entries could you have?

• With 26 letters, you've only got 26 ^ 2 = 676 options.
• If you use numbers too, you've got (26 + 10) ^ 2 = 1296 options.
• If you start using lower case letters (SQL is case-insensitive, but maybe this impacts managed code), then you've got (2 * 26 + 10) ^ 2 = 3844 options.
• Add in some special characters (such as spaces, periods, asterisks, hyphen, underscores, etc...), maybe 10 of then (if the column isn't validated on strictly alpha-numeric), and you've got (2 * 26 + 10 + 10) ^2 = 5184 options.

That's potentially 100 time more than just the 50 US states. Of course, for new development, we'd all prefer some clearly-defined schema with referential integrity and a business-sensible range of values. However the real world of enterprise applications is messy, and you have to be prepared to see messy things.

It sounds simple, but that innocent "state" field can quickly get very complex.