Finally: An Answer To What I do

The most dreaded question for an IT professional is “What do you do”?

I’ve finally found the answer. I solve problems.

What kind problems? All kinds. The key piece is, my efficiency in solving a problem is directly proportional to how interesting I find the problem. It’s true for all IT pros.

For an MIS guy, it’s fascinating to find the best way to get file A to point B while keeping away hacker C.

For a Web Services guru, it’s all about getting data from one place to another, and the further apart they are, the more interesting it is.

I have a lot of problems I find interesting, but the one I find most interesting is how to get user A to use system B and for system B to do something useful with system C while user A has no idea that there is a system C. It just happens.

That is what I do.

If you found this interesting, please share.

Suppress Eclipse Warnings Annotation

When I search for something too many times, I try to remember to post it here.  So, to drop the warnings for type safety when you know all is fine, you can do the following:

@SuppressWarnings("unchecked")
List<CustomerBean>    customers    = (List<CustomerBean>)session.getAttribute(CSRD_CONTACT_LIST);

 

If you found this interesting, please share.

Software Project Failure

I’m on a roll with the LinkedIn rants today 🙂

Do software development efforts fail because: 1) the technical staff is not skilled enough for the work, 2) management has unrealistic expectations, 3) lack of reasonable resources to perform the effort. I would be interested to know your thoughts.

Someone once said that failure can only occur when time and resources are limiting factors. In the case of software, all of the above are true, though the most consistent cause I see is that the process of doing the following in order:
1) Set a completion date
2) Define the requirements
3) Design the software
4) Develop the software
5) Change the requirements
6) Wonder what went wrong

Agile is a good step in preventing failure from the above process except that even shops that use Agile often face that the end date is set before work begins and that unrealistic expectations are set at the same time.

Another ongoing issue is that management’s reaction to bad news about meeting functionality or a date is to throw more people on the project and demand more frequent meetings which pull the people most capable of solving the issue away from solving the issue. This trains developers to not communicate issues until the last minute, which accelerates this vicious cycle.

As Dennis Miller used to say “But that’s just my opinion. I could be wrong”

If you found this interesting, please share.