Disruptive Theory - Latest Comments

Re: You Are In Charge Of Your Dysfunction

Colleen Reynolds — Thu, 15 Dec 2011 20:08:53 -0000

Nice insight!

Re: Dropping The “I” From Interfaces

Ryan — Tue, 23 Aug 2011 16:58:19 -0000

I agree that things like IAuthenticationService are a bad interface name, but there's no need to completely abandon the I prefix. I tend to name things with roles, like IAuthenticateUsers or IProvideMarketData. Also, I set up a color scheme in VS where interfaces are a different color than class names so I can immediately know when I'm using one.

Re: Dropping The “I” From Interfaces

leebrandt — Thu, 28 Apr 2011 11:20:44 -0000

Yes, this is an uphill battle and one that I rarely choose to fight with a legacy code base. But for the places where I control the naming conventions, there is no "I" in interface. :0)

Re: Dropping The “I” From Interfaces

leebrandt — Thu, 28 Apr 2011 11:18:54 -0000

You should be using the interface as if it were the implementation. Treating it exactly the same. That, for me anyway, is the whole point of interfaces. The renaming is to help developers understand interfaces, because lots of developers I talk to don't.

Re: Dropping The “I” From Interfaces

Todd — Thu, 28 Apr 2011 07:50:41 -0000

Removing the "I" from your interface name does not force you to do anything regarding the name of your implementing class other than rename it should the new name of your interface now conflict once the "I" is removed. Why is it important I have "no inkling" I am using an interface? Not sure what I gain by this new ignorance... I am not comfortable changing the naming of my interfaces with the goal to teach developers about the fact you can have multiple implementations of an interface.

Re: Dropping The “I” From Interfaces

Mike Goatly — Thu, 28 Apr 2011 07:45:20 -0000

I agree the "I" is the last bastion for hungarian notation, but the issue for me is that it is quite strongly ingrained in the .NET Framework itself. Using one convention for interfaces that the framework uses and one convention for interfaces that you create seems a little... unnecessary?

But, I promise that the next (non-production :) ) piece of code of any substance that I write, I'll give it a go and see if it feels good to me too!

Re: What I Expect From Myself This Year

Craig — Thu, 31 Mar 2011 03:17:02 -0000

Well, #2 can certainly can help with #1. ;)

Re: Do Software Solutions Put People Out Of Work?

Craig — Thu, 31 Mar 2011 03:05:13 -0000

I really enjoy this topic of conversation. Very geeky, yet relevant to the masses.

Re: Do Software Solutions Put People Out Of Work?

Brian — Fri, 25 Feb 2011 18:09:03 -0000

Oh man... If I could program requirements...

Re: Do Software Solutions Put People Out Of Work?

leebrandt — Fri, 25 Feb 2011 10:50:59 -0000

@phil ... smart-ass

Re: Do Software Solutions Put People Out Of Work?

leebrandt — Fri, 25 Feb 2011 10:39:48 -0000

@Merennulli, I apologize, my intention was not to imply that you actually DO twice the customer volume, but instead to imply that automation allows you to get more done with the same amount of effort. Quite a lot of times, companies are looking at software development, because in order to bring on any more customers, they will have to staff up. Sometimes that's because of manual steps that can be automated. Concentrating on getting the _same_ done with less effort is less desirable to the company. I'm sure there are situations where automation for staff reduction is done. But smart companies would be better off concentrating on the getting MORE done proposition. I'm sorry that wasn't clear.

Re: Do Software Solutions Put People Out Of Work?

Merennulli — Fri, 25 Feb 2011 09:57:34 -0000

While this is true for the most part, there is the harsh reality that, no, it won't double your customers. If you could double your customer volume, the company would have already hired double the staff or brought in temporary programming staff to do this automation long ago. If you can suddenly do double the work with the same staff and the work load fails to increase, work gets consolidated onto fewer people. Someone could get downsized if that fairy tale of doubled capacity happens.

That said, software is long past the days of automating out half the work. In reality we've cut so close to the bone with layoffs and hiring freezes in almost every business and government agency already that the software being written now is to make it practical to do the jobs people are getting burned out on. With the mundane and repetitive done by software you supervise, you can focus on the huge stack of work you've set aside as "not life and death...yet". Maybe one day automation will even let you get a few free minutes to tackle the things foolishly labeled as a mere "high priority".

Re: Do Software Solutions Put People Out Of Work?

Phil — Fri, 25 Feb 2011 09:26:28 -0000

My current project is to write an application that can take a set of requirements and write other applications, including maintaining and refactoring itself, so I'm pretty much screwed.