Reputation
4,390
Top tag
Next privilege 5,000 Rep.
Approve tag wiki edits
Badges
1 12 21
Newest
 Yearling
Impact
~138k people reached

Apr
25
comment Why are deadlines always so short?
@FiddleFreak - Part of the reason developers don't have time to get the job done is because those initial developers on the project "didn't have time" to do it right. And yet, if you look at all the additional time spent maintaining the application after those initial developers "didn't have time", the company could have created 3 or 4 extra applications with the time savings they would have achieved if the initial developers didn't lie to themselves by thinking they didn't have time.
Apr
20
comment Default move assignment and destruction order of members versus the rule-of-zero
If the order of destruction matters then assume your design is bad, unless you can prove there's nothing better.
Apr
11
comment How to effectively compare the (almost) same code which has been auto-formatted?
There is a compare tool called "Beyond Compare" that will compare ignoring whitespace differences if you select to do so. I'm sure there are other tools that have that capability, but that's the one we use. Why you would want to ignore commas or comments, I don't know.
Apr
11
comment Effectiveness of FizzBuzz and Beyond
Of course the "think out loud" technique is only useful if you are looking for programmers who prefer to "think out loud". That eliminates the overwhelming majority of programmers, and arguably only leaves mostly the programmers who are better suited as managers than programmers. After all, thinking at "electrical" speeds in the brain is far faster than thinking at the "mechanical" speed of talking.
Apr
8
comment How can I promote the use of the Builder pattern in my team?
...before you can even begin the process of change. If you come in and establish a "negative" relationship with some of the developers early on then it won't matter how good you are. They'll still carry that opinion with them for as long as you work with them. The ultimate goal is "buy-in" and not just adherence. If people don't buy-in to your ideas but are forced to just adhere to your rules then they'll adhere to the rules but do a lousy job and your ideas will be proven worthless, just like those developers wanted to prove.
Apr
8
comment How can I promote the use of the Builder pattern in my team?
One of the main reasons I was hired at 3 companies that I worked for was because they wanted someone to make the SW team more "professional". Based on a couple bad experiences early in my career, I learned that the new guy coming in isn't going to get much buy-in if they come in and act like a know-it-all. So in each of those 3 companies, I came in and "proved" my chops before I started trying to get buy-in for anything other than trivial changes. Once people WITNESS that you really know your stuff, it is vastly easier to get people to go along. This could take 6 to 12 months....
Apr
8
comment How can I promote the use of the Builder pattern in my team?
You don't have to "forever" work with code that is trash or follow bad practices simply because that's how it is being done. However, if you want to be successful at changing things then you had better prove your credibility first as a minimum. Just about every developer thinks code they inherit is trash. If every company just agreed with the new guy every time without even knowing their true skill level then the trash will turn into a dump. Also, you should take the time to understand why things are done as they are. Sometimes the "wrong" way is the "right" way for a specific situation.
Apr
6
comment How can I promote the use of the Builder pattern in my team?
I don't know the details of your situation but if you came in and tried to change everything without first gaining people's confidence with your skills or not taking the time to learn "why" they do things the way they do then you were treated exactly as you would be treated at just about any company, even really good ones. Actually, especially at really good ones. Once people have confidence in someone's skills then it is simply a matter of making a compelling case for your suggestions. If you can't make a compelling case then there's a good chance your suggestion isn't all that good.
Apr
6
comment How can I promote the use of the Builder pattern in my team?
@MarjanVenema - There most certainly is right or wrong. Just not in the OP's case.
Apr
6
comment How can I promote the use of the Builder pattern in my team?
@rath - It sure seems like incorporating a good validation checking scheme would have been far more useful and more readily received than trying to figure out how to ramshackle the builder pattern into already existing code. Somewhere else you said you want to better yourself. Learning how to get maximum gain for least effort and consequences is definitely an attribute that should be developed.
Apr
6
comment How can I promote the use of the Builder pattern in my team?
Where it is OK to throw caution to the wind and go rogue (sometimes) is when your changes don't affect the interface that others are using. If you want to change an interface then it is just being courteous to at least discuss what you want to do with people that will be affected. Courtesy applies whether you are the new guy or a grisly veteran of the application.
Apr
6
comment How can I promote the use of the Builder pattern in my team?
@Brandon - If you are going to go rogue and fix something "that everybody agrees is wrong" then you'd probably have more success by choosing something that "everybody agrees is wrong" rather than choosing something that at best has different camps on the topic;like immutability. A good design/architecture makes immutability high cost for practically no reward. So unless your team has been having problems because they are using setters then you weren't fixing a problem at all. OTOH, if this has been a source of frequent bugs then it seems like the ramifications justify a team decision.
Mar
30
comment Rule of thumb for deciding which class a method belongs to
My rule of thumb is if it can legitimately go either way then you are missing a class that ties them together or you named/defined your classes very poorly. In regards to your example, I think you are missing a class to tie them together.
Mar
16
comment Per my design requirements, does this design hierarchy seem reasonable?
No the design does not seem reasonable. As others have already said, they don't know what you are trying to accomplish. The names you are using make it difficult, if not impossible to understand what you are trying to achieve. The names of your classes are every bit as important as your "design" choices. However, I suspect you are trying to use generic names. Unfortunately, if that is what you have tried to do, then your generic example isn't providing enough context to provide meaningful responses. So I recommend using something more concrete.
Mar
1
comment Are optional parameters helpful or a hindrance to application maintenance?
Try writing an app in C# that interfaces to Excel without using optional parameters. That should answer your question beyond any reasonable doubt.
Feb
29
comment Scrum - Dealing with failed sprints and deadlines
@DocBrown - People love to blame management but in this case, I don't agree. The developers said 3 weeks. Management gave them more time, not much more, but more time. I can't recall the last time I've ever had that happen too me. Usually, management halves my estimates and then the customer halves them again:( Blame management in those cases, but they never get blamed, the developers always take the blame for being too slow or not working long enough hours. Thus, my estimates now take those tendencies into account and everyone ends up happy.
Feb
29
comment Scrum - Dealing with failed sprints and deadlines
@Jeff - No Jonathan missed the boat entirely. It is not like you write one algorithm and you can detect all the mines or some requirements are optional. Good luck testing your app to make sure it detects properly without a decent user interface. Good luck meeting the minimal operator skill level standards without a decent UI. Good luck selling your detector when the soldier has to stand in the open field for minutes waiting to determine if a detection occurs. There are simply applications, and there's many of them, where 80% of functionality is no better than 0%.
Feb
26
comment Scrum - Dealing with failed sprints and deadlines
@DocBrown - That's fair. I was jumping in on your tit-for-tat comments pointing out "sarcastically" that different domains have different kinds of customers and scope is frequently not negotiable. Normally it is either time or money that is fixed along with scope in my domains. I think you both have different kinds of customers and that is where disagreement lies. I agree that it was management failure to believe that a production worthy product can be delivered in 1 month unless there's already a working product with just a few tweaks needed. Especially if the expertise isn't already in house
Feb
26
comment Scrum - Dealing with failed sprints and deadlines
@gbjbaanb - I know people don't believe it but companies that successfully use Waterfall do many of the same things that "Agile" takes credit for doing. And they were doing it many years before "Agile" even existed. Nobody who successfully uses Waterfall does one step at a time like Waterfall implies. There's overlap, iteration, multiple builds etc..Waterfall is just a guide that is loosely followed. There's really not a lot of "new" things that the "agile" movement has brought to the table, unless you want to count adding more useless meetings and unacceptable work conditions.
Feb
26
comment Scrum - Dealing with failed sprints and deadlines
I guess my entire career has been based on "clear management failure". I can't recall ever working on a project where "time or cost" and "scope" weren't explicitly called out in our contracts. I take that back, if we are developing "in-house" applications then it was more of a what you can get done in the specified time-frame. But external customers, I have obviously been working for the wrong management as we agree to deliver exactly what the customer asks for. I guess I have a character flaw because I prefer to deliver all of what the customer wants instead of just some of it:(