Over this weekend I read some of W. Edward Deming’s Out Of Crisis. Deming was a man credited with the success Japanese industry had after World War II. I’m 100 pages into the book and have already pulled out much information

Saturday I read:

… Next day, in one of his plants, a superintentant showed me two pieces of a certain item from two different suppliers, same item number and both beautifully made; both met specifications, yet they were sufficiently different for one to be useable, the other one usable only with costly rework, a heavy loss to the plant

In short: context is important, and understanding context more so.

A similar thing just happened to me.

A few months ago I created some import functionality for a client - import a file and add it to some table in the database. So we followed the spec exactly: wrote that file to a table. Writing to that table in isolation, because the specs (even through digging and talking with the customer) specified only that.

Today I find out that this table actually is a major reference table that needs to tie into the app in two different places. This discovery means we have to revisit that import even though we implemented it exactly per specification the first time.

Not knowing the context caused extra work and added delay to a software project that was already under schedule risk

Lesson here: Your consultant wants both of you to succeed. As much as you can, provide context for where this functionality will fit in the bigger picture. In exchange for that you’ll get better more quality product in the end, and probably your product will ship faster, and have fewer bugs, than without that context.