“When people didn’t think about quality until they were 6 weeks in, they didn’t know how to do it anymore…you get too far in and you never recover.”
Nick Van Weerdenburg explains why quality matters on day 0 of your development project.
Everything I don’t like about unit testing
…brilliantly summed up by Alexey Golub in “Unit Testing is Overrated”.
My main complaint is that they greatly expand the complexity of the code with interfaces and abstractions that only exist for the sake of the unit tests, without actually testing the application the way it will be used. Users don’t care how high your code coverage is if the app doesn’t work.
He comes out swinging right after the bell:
Focusing on unit tests is, in most cases, a complete waste of time.
Kinder, gentler version:
If you treat unit testing as a goal in itself, you will quickly find that, despite putting a lot of effort, most tests will not be able to provide you with the confidence you need, simply because they’re testing the wrong thing. In many cases it’s much more beneficial to test wider interactions with integration tests, rather than focusing specifically on unit tests.
The alternative:
Writing high-level tests that are driven by user behavior will provide you with much higher return on investment in the long run
Amen.
SQL is not a modular language
When will I ever learn?
INSERT EXEC statement cannot be nested
Until it is, here is a great overview on How to Share Data between Stored Procedures by Erland Sommarskog.
Rule 14 in the wild
“What if we just used NVARCHAR(4000) as the default datatype parameter for any query, regardless of what datatype the table has in it – like numbers or dates?”
Brent Ozar with an interesting example on why (almost) everything could be nvarchar.
Never rewrite, always fix
There is, however, a clear line of heredity and succession which connects my 1986 computer to my bought-in-2018 one, the same way there’s a line of heredity and succession between the first Benz and the latest one…the so-called “x86 architecture”
Here’s an entertaining essay on the dangers of a clean sheet re-write, aka Rule 20.
Simple rules for keeping dev teams out of trouble
I’ve been leading small software development teams on big projects since 2004. Painful experiences taught me some simples rules to make it less painful. Here they are, presented in order of discovery:
-
-
- If it can be null, it will be null
- The clipboard is a cruel mistress
- Size really does matter
- Inside every small problem is a larger one, struggling to get free
- Every bug you fix creates 2 more
- The law of the motorcycle shop is non-negotiable
- Cleverness is the mother of regret
- Just in time requirements are neither
- Don’t solve problems you don’t have yet, Nostradamus
- Later == never, temporary == forever, shipped > not shipped
- Only change 1 thing at a time
- Always redo, never fix
- Finish the most important feature first
- Tomorrow you hates the code you write today, so don’t plan too far ahead
- Character data is nvarchar(max) until you can prove otherwise (see rule 2)
- Schrodinger’s Spec – you can know what the client wants, or what will be best for them, just not at the same time
- Solve the toughest problem first
- Legacy == proven. Try out the newest thing on your own time and dime.
- Naming stuff is hard
- You’re not going to reuse that
- Process: never fix, always redo. Code: never rewrite, always fix
- Fix problems upstream
- Never use a black box when a text file will do
- I will put my strongly typed boot up your loosely coupled [redacted]
- The original sin of code is writing it
- An unbound task is the Devil’s workshop
- Developer time is vastly more expensive than CPU time
-
