Reputation
6,779
Top tag
Next privilege 10,000 Rep.
Access moderator tools
Badges
3 21 30
Newest
 Nice Answer
Impact
~172k people reached

Mar
16
comment Should we test all our methods?
Why would you check that your DAL has only been called once?
Feb
20
comment Cheap implementations in fundamental TDD
@alfe and to answer your question of how strict you should apply something: dogma is never the answer to anything. Keep using your brain. When you start to rely on strict dogmatic application of anything, everybody loses.
Feb
20
comment Cheap implementations in fundamental TDD
@alfe What then: you add more test cases. TDD doesn't require you to be complete from the start. In fact it specifically allows for requirements and implementations to change over time and to be refactored / added to with changes in perception of what the behavior should be. Test cases that test for behavior that is later found to be redundant can and should be removed. Test cases are a living breathing code base, just like the production code. Think of them as the dynamic documentation of your requirements (which change over time) and as a history of bugs solved.
Feb
20
comment Cheap implementations in fundamental TDD
@alfe instead of expanding an existing test case, you can always add an extra one. Each test should cover just one aspect of a function/method. Doesn't mean there can only be one assert (it often takes more than one assert to verify an aspect); but your second scenario should probably have its own test method within the testclass instead of being added to the first.
Feb
20
comment Cheap implementations in fundamental TDD
@Alfe "... or write the correct solution anyway" How would you know it is correct and more importantly that it remains correct? Quite often ensuring proper test cases before hand may seem "over the top" for the initial implementation, but they start shining when someone inadvertently makes a change that introduce a bug and that bug goes unnoticed because the test cases where done after the fact and may well suffer from myopia by the developer who thought (s)he was already done.
Jan
26
comment Two contradicting definitions of Interface Segregation Principle – which one is correct?
Cool @user61852 :) (and thanks for the credit)
Nov
7
comment In an Agile Environment, who is responsible for software architecture
Because of the questions like @DaveHillier poses, I tend to use "s/he"... (Thanks for this great answer by the way, puts reality back into the "the team is/does/has/owns ..." cliches)
Sep
27
comment Are any top software products outsourced? (offshore or otherwise)
@RossPatterson: Where does it say that they our outsourcing development of their virtualization solution? I may be reading it wrong (just scanned it really), but I see MS outsourcing the operation of their virtualization platform, not the development of it?
Jul
19
comment Organizing solution / project structure and classes for Line of Business Application (LOB)
In this case I don't agree with the YAren'tGNI approach. Separation of concerns is far easier to achieve and keep up when unrelated code is in separate assemblies. And of course separation of concerns helps achieving better design with high cohesion and low coupling. Having to add an assembly in your references makes dependencies visible and makes it harder for dependencies "to creep up on you". Use it to think about whether you actually need that code and/or whether is is where it belongs. It's a LOT simpler to code this way than having to loosen badly intertwined dependencies when YAreGNI.
Jul
19
comment Desktop client server application, limiting text area field compromise with customers
Forget about size restrictions and think about lazy loading. Don't load the notes unless they are actually needed to display or edit. So don't include the notes in any queries used for list displays, always filter server side if a note is in the filter expression, etc.
Jun
28
comment Design Patterns for creating tasks
Oh and using observer would make your observer of the Entity certainly non-anemic... Your Entity class still may or may not be anemic, but the observer certainly won't. The desire not to have anemic classes is very good, but you should still not put code in a class just to make it non-anemic. The code to instantiate the Task indeed does not belong in Entity as it would introduce unwanted (and unwarranted) coupling. Any code added to Entity should be related to Entity.
Jun
28
comment Design Patterns for creating tasks
Perhaps your confusion stems from treating design patterns as code examples. A design pattern may have a code example to explain it, but it is never limited to that example. Design patterns are much more than just code examples. Design patterns are ways of talking about code and talking about general solutions to common problems. It is up to the developer to apply a design pattern to his/her specific problem by amending the explanatory example to his/her specific case.
Jun
28
comment Design Patterns for creating tasks
Whether your classes are anemic has nothing to do with using or not using Observer. Furthermore the Observer pattern is not restricted to passing along just "simple" parameters. The observed can pass along anything you need to the observer. So you could simply pass along the Entity instance that was changed and the observer can pick whatever it needs.
Jun
20
comment Mental Models or Real-World-Metaphors for Functional Programming
@Doval: Thanks for taking the time to explain. Learned something :-)
Jun
18
comment Mental Models or Real-World-Metaphors for Functional Programming
Curious: can I infer from your example that in Haskell "things flow left"? Meaning that execution starts at the right end of the statement and results of the right most function are input for the one to its left? That would present an interesting challenge for someone used to OO fluid coding where each method of a class returns the instance it worked on as its result (including its now changed state), which means that "things flow right". Meaning that in fluid coding your examples would become smallest = SomeInstance.Sort.Head and smallestEven = SomeInstance.FilterEven.Sort.Head.
Jun
15
comment Is method overriding always a violation of Liskov Substitution Principle?
@Phoshi: Ah that's what you were getting at. Yes, indeed, I just responded to the "is overriding always a violation of LSP". And for me overriding is linked to classes... I trust you upvoted DocBrown's answer then :)
Jun
13
comment Simplifying data search using .NET
Use SOLR?
Jun
12
comment Is it customary for software companies to forbid code authors from taking credit for their work? do code authors have a say?
Would you like to be called/mailed by your company's customers to provide support even after you have left that company? And don't think they wouldn't be able to contact you if the source doesn't contain an (e-mail) address or other contact information. I wouldn't like it. And therefore I'd be more than happy to remove my name if and when my employer decided to provide the source with their software.
Jun
12
comment Is method overriding always a violation of Liskov Substitution Principle?
@Phoshi: Yes, so? That doesn't preclude cases where you do have base behavior and descendants can add to it as necessary. After all a class is a type. Calculations in payment and salary programs for example. The ancestor will do the basic calculations, descendants may add extra's, effect different values for parts of the calculation depending on whatever. Of course in any salary program the calculations may well be an amalgamation of Strategy patterns and each may in effect have its own inheritance hierarchy to deal with all variables and variations.
Jun
12
comment Is method overriding always a violation of Liskov Substitution Principle?
@jk. How? Augmented behavior in payment programs could be a getting a value from somewhere for the calculation of rebates, an additional rebate, ... whatever ... all variations on calculating (base) rebates from the ancestor, all still within SRP.