semicolon.net

My C# Generic Singleton Base Class

2009-06-26T21:41:00.000-07:00

public class SingletonBase<T> where T : class
{
    static SingletonBase()
    {
    }

    public static readonly T Instance =
        typeof(T).InvokeMember(typeof(T).Name,
                                BindingFlags.CreateInstance |
                                BindingFlags.Instance |
                                BindingFlags.Public |
                                BindingFlags.NonPublic,
                                null, null, null) as T;
}

Adam Machanic's Grouped String Concatenation Challenge Results Posted

2009-06-02T19:46:00.000-07:00

http://sqlblog.com/blogs/adam_machanic/archive/2009/05/31/grouped-string-concatenation-the-winner-is.aspx

I came 9th. Looking forward to the next challenge.

New Celko article on constraints on Simple Talk!

2008-10-27T07:33:00.000-07:00

http://www.simple-talk.com/content/article.aspx?article=589

Everything old is new again - deja vu - new boss same as the old boss, etc.

2008-10-23T08:14:00.000-07:00

http://aws.amazon.com/windows/

Mainframe pricing for Windows!

Stupid Human Management Tricks - Part 1

2008-10-20T15:17:00.000-07:00

When management loses the respect of employees, it is almost impossible for it to be regained. Many of the stupid human management tricks tend to lead directly to a loss of trust.

Lying to Employees

I think this is the biggest one. Now there are always exceptions and special cases and whatever, but employees are pretty smart (I guess that's another list about management, but back to the lying...).

When you contemplate telling employees a lie, you should start from the assumption that they will eventually find out the truth.

There are certain categories of lies which I guess should be addressed:

Lies of Exaggeration: Employers will very consistently exaggerate the position of the company in many ways. They will exaggerate the quality of the work environment, the financial stability of the company, the level of sales. Often, they will do this publicly to the stock market and could eventually face criminal or civil proceedings. I would group all of these sins of exaggeration together as innocent lies which sometimes get out of control and turn into real big problems. When it comes to employees, they will usually forgive these, because they understand marketing and the lies that come with it.

Lies of Subterfuge: Employers often have strategic or tactical goals and they would like to keep employees in the dark. Usually, this is a particularly stupid management trick, since your employees are the only people that can actually cause your company to achieve your vision, but this would seem to be the #1 case where employers justifying lying in their heads. It rears its ugly head specifically when an employer plans something like an office move or outsourcing. If employees get whiff of a location change or outsourcing, they will panic and abandon ship. If management is not actually good at getting the new location or outsourcing online, they will have done damage which far outweighs the cost savings because:

Human capital is expensive because it is valuable (you were outsourcing something expensive in the first place, right?)
You can always get human capital cheaper on an hourly rate, but management never fails to factor in costs of training and the costs of experience loss. Gosh, it's so hard to figure these out, and apparently so hard that it's better to simply risk the enterprise than figure out a worst case scenario and do risk mitigation.
If you treat people like a commodity, you will get a commodity. So all the brilliant out-of-box solutions they came up with aren't valued, they can take them elsewhere. Maybe you'll get some brilliant offshore people with great ideas, but eventually, won't they get expensive or you'll be outbid for them, too?

Employees will never forgive lies of subterfuge. In fact, it will cause them to be more and more suspicious and they will find plots where there is only either incompetence or brilliant plans.

In fact, all employer plans they don't agree with or immediately understand come down to 3 possibilities in their minds, and none are good for your company:

Conspiracy: In this case, you are a sack of shit and they will figure it out and go elsewhere. But that was the point anyway. Of course, it doesn't bode well for your company, since anyone who doesn't leave doesn't trust you anyway.
Incompetence: In this case, you are not only not smarter than the majority of your employees, they know it, and they don't respect you because of it.
Brilliance: A plan so brilliant they don't understand it; in this case, you have employees who are probably not up to the task of carrying out your plans with success.

Your final problem is that option 3 is so stunningly rare and unlikely that it does really point to one of the fundamental problems of forging a team: The team needs to be (on balance) as smart as you are and able to absorb the vision and respect it on its own merits.

semicolon.net is alive again

2008-10-17T07:21:00.001-07:00

After many years, I'm reviving the semicolon.net domain for blogging about software development issues.

Some upcoming posts I am planning will discuss stupid human management tricks and the nature of production.

What is production?

2008-10-17T07:07:00.000-07:00

Production is everything that is day to day operation of the software - INCLUDING things which are exceptional but are still done on a regular basis.

There is NO point glossing over things which users are going to need with a frequency more than yearly - because before you know it, they are going to need the system to accomodate what you have said is too exceptional to build into the system.

I'm not advocating building everything into the software part of the system. But a system really includes the maintenance, the support staff, the processes and everything required to operate the IT enterprise.

In the same vein, the majority of the lifecycle of software, you are going to be in production, so your actions prior to production should be most closely a reflection of what they will be in production. e.g. If you have an operation which in production you would fix a package and reload a file because an ETL package breaks, then in pre-production when you are loading an entire data warehouse history, it makes little sense to fix the package AND go through all kinds of abnormal operations and creation of throwaway code to fix previously loaded data, when re-loading all the data with the fixed package will:

Validate the new ETL package
Validate the fixed package over a broader range of dates
Increase your level of confidence that the package changes have not broken anything
Avoid having to test code which will be thrown away
Avoid having to think how to test the throwaway code

Apparently understanding production is a big problem these days and it comes from most developers having too little experience running production and too much compartmentalization and separation of IT from the business in general.