Friday, March 25, 2016

If You Write The DataBase First You Are Doing It Wrong!

In an epiphany, I figured out why developers want to make the database first. In root cause analysis fashion, let's play the 5-whys game and find out.

1. Why start with the DB? You need data in order to start developing the rest of the app.

2. Why do you need data first? Because you aren't practicing TDD.

3. Why aren't you practicing TDD? Because it takes you longer.

4. Why do you think it takes longer? Because it means you have to write more code.

5. Why does TDD necessarily mean that you have to write more code? Because you've written Unit Tests before and its difficult to write them when your business logic depends on the data, so the Unit Tests become lengthy, take a long time to run, and are costly to maintain.

So it comes down to a myth that is invented from having done testing wrong in the first place. Perhaps there's an assumption that TDD is about testing, when it is really about design. Dr. Dobbs sums up the concept in this article, basically pointing out that the tests make you think about the code. There are endless sources on the web, in books and in magazines that can take you through the details. I will be staying focused on how TDD helps avoid the costs of developing the data layer first.

If your development efforts start with a test, the first thing you may soon notice is that you will need to provide some kind of data to the business logic. However, rather than writing a database right then and there you will use one or more of several patterns for substituting an actual DB in your code - repository pattern, resource, fixture, stub, mock, etc. This will allow you to focus on what the app DOES instead of the low-level details of a datastore. You will control the data that drives the logic in a scientific way for each scenario by providing the combinations of values that are expected for each scenario. The art is in knowing how to write the tests, which takes practice.

Imagine if you had a DB first and you operated under the assumption that certain bits of data would be needed for certain methods of accessing the data would be needed. Now when it turns out they are not needed, or that your assumptions were incorrect, you've actually just done a lot of unnecessary work - e.g. wrote more code which took longer and wasn't needed.

Eventually, and maybe in the first few iterations of test-then-code, you will begin to write some models that can be represented by a data model. As your application takes shape, you should be safely refactoring so that the entire application becomes more cohesive in time. You have the tests to back you in the refactoring process. One of the reasons to start TDD at the system interfaces.

Additionally, as you add features during the project, your manual testing or even Unit Tests will take longer to execute and you will end up creating and deleting data and having to update data update scripts to set up a bunch of data which is more code to maintain. In the end you will end up doing more work than of you'd written the tests while designing - iterating test, then code to make it pass, then test...bit by bit.

When you eventually get to the point where you will need to integrate, you will now understand what you really need to persist to a database, but not until it is needed. If you start in this way, the way of TDD, then you will know that you do NOT need the database to write the application and you will see it as the outer layer of the onion that it is.

One final nugget - the most important reason for a repository pattern is NOT so that you can swap the underlying data store technology, though it is a compelling myth. More details about this and how to start TDD in future posts.

Tuesday, March 1, 2016

Const and Static in C#

I learned the true difference between const and static in C# when it comes to class members. This did not come the hard way, but through a PluralSight course. I'm thankful for that!

Here's the difference:

const - set during compilation time, it seems like it is inlined. In other words if you have a const FEET from a class Yard like so:

class Yard
public const int FEET = 3;

and you use it like this:

var bar = baz * Yard.FEET;

You would be ok if Yard was in the same assembly, but if it's in another assembly and Yard.FEET changes, but the calling assembly doesn't get recompiled it'll still have its old value. Plus a const cannot be changed once compiled so you cannot compute it from something else like a config value.

With a static readonly member, you gain the benefit of computing the value at runtime AND if it the value changes (either by config or by code) and is in a separate assembly from the consumer (think GAC here) your calling code will retrieve the the new value.

Why use a constant ever? It's a bit more efficient during runtime since it gets inlined and saves a call. But let's be honest here, if you are using C# is that minor gain in efficiency really worth it? If that bit of performance makes a difference in your world, wouldn't you be using C or C++ instead? I'm sure a case can be made, but its not likely doing to be one unless you have millions of calls for the same thing. In that case there may be other optimizations that come first. Just saying...

Saturday, February 20, 2016

ABC Mouse Review

Having children during an age of technology means that children will be using technology to play and learn. One very popular educational children's game is ABC Mouse ( The game is very well put together and well advertised. It's a product of Age of Learning, Inc, a global initiative to prepare children for a successful school experience.

The game features age-appropriate activities ranging from puzzles to stories, songs and coloring. For example, there are original alphabet songs, counting games, matching games. Another key feature of the game is the ticket system. Each game produces a few tickets (similar to tickets at certain mouse themed children's pizza restaurants) that can be exchanged for prizes. The prizes are either related to the in-game fish tank, the hamster maze, the house, or avatar. Once a certain series of activities is completed (4-5 theme related activities) a prize and larger amount of tickets are awarded.

The reward system is pretty good and keeps children interested and motivated to play more. Tickets are earned but can also be purchased. There are two key things I would like to see from this game - and in the education system in general - goal setting and investing.

It would be great if the system had a way to set up a goal and work toward earning that goal. For example, if a specific fish costs 200 tickets, the game should have a way to encourage a child to set up some savings goal to earn enough tickets for that specific prize.

Another fantastic feature would be a way to invest tickets in something that produces tickets over time. Perhaps certain prizes like a specific fish or combination of fish could produce tickets if fed regularly. In any case, a mechanism to learn investing would be great. Currently, if a child wants more tickets, they have to work to earn tickets or have their parents buy tickets for them.

All in all, the game is great and I would recommend this to others. I will be making the suggestions to the makers of this game about goal setting and investing.

Sunday, February 14, 2016

JavaScript : measuring performance

I recently learned a couple great tricks for measuring performance in JavaScript. There's always the profiler in the browser, but that's a bit verbose if you need to just A/B two ways of doing something. The following techniques are great lightweight approaches that you can use when writing or performance tuning some code.


basically it returns NOW as in RIGHT NOW which you can capture in a var for later use. Here's a basic pattern for use:

var s =;
//do something
console.log( - s);

this will log the time "do something" took to complete in ms.

performance is a property of the window object, therefore it is NOT available on nodejs. You can use the following in that environment:

2. console.time("key"); console.timeEnd("key");

use it like this:

//do something

depending on the js engine, you'll get an output like:

"key" 3.002 ms

If you want to measure more than just the execution time, like memory usage, i/o usage, and processor use these quick-and-dirty functions won't get you that. Look for a future post on those topics...

Monday, February 8, 2016

Credit Card EMV Security Chip

I was at the checkout yesterday and they started using the new chip reader. First of all, I'm glad this is more convenient than the old when you have to jam the card just a bit further into the machine or it won't take. Not only is it less convenient, but it's still only marginally more secure.

You've heard the saying "Something you have, something you know", right? It's about multifactor authentication, that added layer of security which means someone can't just have something and gain access to the secured entity. In the case of the CC this is an authentication which is missing. The clerks can check your ID, but most often they don't. So consider that for in-person transactions there is no authentication other than you have the card. Something you have.
There is some hope for the future though since eventually the chip-n-sign cards will maybe be converted to chip-n-pin cards. In my experience you don't have to sign for a lot of transactions, only over certain amounts or even at a place you visit often. From what I can tell, the system doesn't even really authenticate against the signature anyways its just some form of extra work for the consumer - perhaps another illusion of security.

Credit cards are easily dropped, lost, stolen (by someone you know or pick pocketed). Most of the time after, they can just be plugged in and used without anyone knowing since there is usually no ID check.
According to what is presented on, with their "nothing to see here, go back into your homes" message - it's not only going to cost over $16-billion to switch to chip-n-* cards, but there will also be an extortion style switch to merchants to purchase the POS devices that read the chips or else pay for the fraud. Ultimately the costs will be passed down to consumers and/or investors. The site claims chip-n-pin cards reduced fraud in Europe, by how much it didn't say.

But, since any measures for improving security will result in increased inconvenience and a redoubled effort to hack the new thing. Two things will result - added inconveniences for consumers and the thing will eventually be hacked anyways. I would propose using a thumbprint reader, but its very likely that would get hacked too. So lets just stick to convenience at scale and focus on making thieves pay for their crimes instead of everyone else.

Friday, January 29, 2016

How To Write More Maintainable BDD Tests

Given we are writing BDD style requirements
And we are using cucumber syntax
And we want to be able to respond to changes
When we write our requirements
Then we should write them in a way that requires as few changes to them when requirements change
And we should minimize the number of tests that are impacted by changes in requirements.

We can write such tests in the following way:

Feature: Say Hello
User Story: As a marketer, I want the system to greet users by name when they log in so that the system feels more user friendly.

Given a user with the name "bob"
When bob logs in
Then the system should say "Hello, Bob!"

Since this is a simple case, it is sufficient to write the test in this way.

For a more extensive use case that is dependent on bits and pieces of data from many sources with complex business rules, it would be better to define the test cases in the following way:

Feature: Greet User
User Story: As a marketer, I want the system to provide customized greetings to users based on their purchasing habits so that the users will be more likely to increase their overall purchases.

Wednesday, January 27, 2016

Lean Change

I've recently caught wind of Lean Change - basically a way to achieve continuous improvement. It seems the key is regular open communications. I was in the hot-seat for representing our team of five recerly in a QA event put on by CQAA(Chicago Quality Assurance Association). The lab was to put together an elevator pitch to sell BDD to an executive (for some reason we chose executive). So here's me as a developer "pitching" the event speaker acting as an executive.

We thought we'd try to sell on cost reduction, reduced time to market, improved quality, and Google does it so should we. I did my best but was met with resistance and the proposition that QAs and BAs were not doing their jobs and/or would not be needed in the new world order of BDD. Since I was a developer in a room full of QA engineers, I jokingly confessed that we would no longer need QA engineers if we used BDD.

This was basically a sweeping change approach and the pitch was a hard sell. I would not recommend selling directly to execs in most cases. Follow Lean Change - get folks involved in the change. Change a little at a time, but don't make anyone feel like they are the ones you want to change - QAs don't do this to DEV and DEV don't do this to BAs. It's really about working together as a team to resolve the issues, not about imposing change on others.