20,867 reputation
557100
bio website
location Toronto, Canada
age
visits member for 3 years, 7 months
seen Apr 11 at 1:22

"Enterprise" developer/architect with an EE background and experience/interest in:

  • Microsoft .NET / Visual Studio
  • Delphi
  • VB/VBA (although I try to forget)
  • SQL Server, SQL CE
  • Web Services (SOAP, WSE, WCF)
  • Web Applications (WebForms, MVC, JS)
  • Embedded Systems (HCxx, PIC, etc.)
  • UI Design & Data Visualization
  • Project Management
  • and probably a bunch of other things...

Apr
15
awarded  Good Answer
Apr
9
comment Why is “Select * from table” considered bad practice
This is utter nonsense. String comparisons are used everywhere in practice, and they're not slow. The fastest databases available today are distributed hash tables that take strings as keys. I can assure you that I'm very fussy about performance and know a whole lot about optimization, and the penalty for string comparisons vs. primitive type comparisons is completely irrelevant in every instance except maybe for operating systems and microcontroller software. The primary factor in performance is I/O; secondary is the computational complexity, e.g. O(N²) vs. O(N).
Apr
8
awarded  Good Answer
Apr
8
comment Why is “Select * from table” considered bad practice
No other points that I can think of - this pretty much covers it. Too bad my +1 can't put this over the crap that the OP accepted way too quickly...
Apr
8
comment Why is “Select * from table” considered bad practice
You've got to be kidding me. The string comparisons are several orders of magnitude less expensive than the actual database operation. The fact that you would even suggest that this matters one whit in practice is proof positive that you've never even attempted to profile it.
Apr
6
comment Why do projects opt to stay on an older version of the .NET Framework?
Being 5-10 years old usually is a pretty good reason. If it were a car, it would be out of warranty. It's a similar situation with software; unless releases are very slow/infrequent, it's probably no longer supported or only minimally supported as a legacy product. If there's any notion of plugins or integration, most of it probably won't work on the old version. And lack of updates means that potentially serious security flaws or other show-stopping bugs haven't been fixed and might never be. And of course, as you mention, going up 1 version now is far less expensive than 3 versions later.
Apr
6
comment Why do projects opt to stay on an older version of the .NET Framework?
I've never heard this quote from Pournelle. Are you sure you're not referring to "perfect is the enemy of good"?
Apr
6
answered Strategy for storing passwords/credentials in the context of continuous delivery
Apr
6
comment If TDD is about design why do I need it?
How can it not be what you're saying? Your answer starts with the phrase, TDD doesn't only help me come to the best final design.... I don't care about the rankings of answers, I just happened to be brought back to this question due to an inbox alert. I think your answer would be fine if it didn't use the phrase "the best", that's all.
Apr
6
comment Why is “Select * from table” considered bad practice
Really? You think accessing columns by index instead of by name is a good idea because it's faster? Talk about micro-optimization... you're talking about queries that are, at minimum, on the order of several milliseconds, and you're saving maybe a dozen CPU instructions at the very high cost of any kind of maintainability. Hard-coding column indexes is "an error waiting to happen" - doing SELECT * is almost never going to affect the correctness of any half-decently designed program.
Apr
6
comment Why is “Select * from table” considered bad practice
This is a better answer than the accepted one (at time of writing this comment), but it still misses the most important point, which is that retrieving all columns virtually guarantees that no index will ever cover the entire query. The "overhead" of a few extra columns is nothing compared to the overhead of doing table scans, index scans, and bookmark lookups instead of faster seeks/range scans/skip scans.
Apr
6
comment Why is “Select * from table” considered bad practice
Terrible answer. Almost none of the major frameworks today care about having extra columns in the result set. Even if you don't use a framework, most of the time SELECT * should work - I mean, you are referencing columns by name, and not by index, aren't you? Index-based mapping is just bad. There are plenty of reasons not to use SELECT *, but this isn't one of them.
Apr
6
comment If TDD is about design why do I need it?
Uh, so you're saying what exactly, that a design is the "best final design" even if it doesn't work at all, and therefore TDD is the best approach because it helps you get to that suboptimal/nonworking design in fewer attempts? I think your last sentence is really what you should have said, instead of anything about a "best design". TDD is a faster way for mediocre-to-average programmers to create loosely-coupled components. That certainly does not make them the best designs, only better than the worst or perhaps average designs.
Apr
5
comment If TDD is about design why do I need it?
See for example Ron Jeffries' pathetic attempt at a Sudoku solver. If you really think about the problem you'll realize that it's combinatorial NP-Complete, and the only worthwhile strategy is apply the process of elimination (constraints). Now admittedly, most people using TDD will be solving straightforward business "problems" that are IO-bound, and don't care about things like elegance or computational complexity, but still, it's a cautionary tale in the limitations of TDD. Ron wrote tests first, hammered away at them, and came up with something very modular and totally useless.
Apr
5
comment If TDD is about design why do I need it?
I'm not sure if I didn't notice this answer before or just didn't think much of it at the time, but I take issue with the statement that TDD has anything to do with the "correct" or "best" design. A bubble-sort will pass the same functional tests as a quicksort, and a string array scan will be just as green as a trie, but that doesn't necessarily make any of those solutions - even the faster ones - the best final design. In the worst case, TDD can encourage some (not all) programmers to perpetuate naïve designs that some very basic analysis could have vastly improved.
Apr
4
awarded  Nice Answer
Mar
5
comment What should I do when I've already waited too long between commits?
I will qualify my statement, however; the exception is if you are using a DVCS such as Git or Mercurial, in which case the tried-and-true branching model is to make all changes in a development branch, stabilization branch, or short-lived feature branch. However, this also depends on making no direct commits, ever, to the master branch, and only merging from specific branches. I don't want to go off on too deep a tangent in a comment thread, but my previous comment applies mainly to centralized VCSes (SVN/TFS/etc.)
Mar
5
comment What should I do when I've already waited too long between commits?
I have to also disagree with branching as a viable strategy for architectural changes or other "destructive" changes. That just leads to a nightmare of merge conflicts and post-merge bugs. In the long run it is far, far less painful to figure out a way to break the major change into smaller, backward-compatible changes, or, in the worst-case scenario, use what Fowler, Humble and the rest of them call Branch By Abstraction (which is not actually a branch at all). Both of these strategies imply small and focused commits.
Mar
3
awarded  Good Answer
Mar
1
comment What should I do when I've already waited too long between commits?
Incidentally, this is why teams using Git generally hate merge commits and request/require rebases instead; merge commits break bisect and other techniques commonly used to isolate issues, because so many changes are stuffed into one huge commit.