Category: Management

Posted on
by

When armed guards need to be stationed at the Human Resources office, it may be an indication that something has gone terribly wrong with your project. This is precisely what happened at Arizona State University after they rolled out a new Oracle application to manage their payroll (requires wsj.com subscription, sorry). According to the article, this was the result of ASU’s new approach to managing technology projects. Part of this new approach includes admitting that there will be problems up front, then working through them with some help from the people using the problem software. In other words, release early and often.

In many cases, that isn’t a bad approach, but a line needs to be drawn somewhere. When people don’t get paid, they get upset–rightfully so. In the end, one could label this project a success since they are now cutting paychecks at a lower error rate than they had with the old system. But, over the course of several botched pay cycles, enough animosity has been created towards the IT department that it will be difficult to overcome. Asking one of those who had difficulty paying their bills how successful the project was is unlikely to produce a positive response. This won’t make rolling out the next project any easier.

So, if armed guards may be a necessity, think twice before applying the beta tag to a project that should really be more rigorously tested.

Posted on
by

Dealing with a group of people’s time off can be a headache. Spread that group across several locations and that headache quickly turns into a migraine. There are hundreds of applications to help with this which range from the very rudimentary to the overly sophisticated. WhosOff, a free web application, looks to have hit the sweet spot here. It is easy to use, but also includes more advanced features like time off approvals. Since it is web based, it is simple to deploy and has the added benefit of allowing the whole team to see who’s out of the office at any given time. Sharing this information with the team becomes more important as the team grows and is difficult to do if the information lives only on the manager’s computer–or, even worse, in their head. WhosOff will get this information in front of the team where it belongs without burdening the team members or mangers with unneeded overhead.

via lifehacker

Posted on
by

You know about object-oriented programming and all its goodness. Now, step up to abject-oriented programming. Learning to work in an abject-oriented (AO) environment is important since there is a high demand for people that can maintain existing abject code (there is a lot of it out there). Greg Jorgensen’s Introduction to Abject-Oriented Programming will get you started by touching on some of the high points of AO. Here’s an excerpt that describes an AO best practice:

A good time to write documentation is when someone in the department gives two-weeks notice: use that time to make sure the departing team member documents all of their code.

Make sure you peruse the comments on that post. Its amazing how many people disagree with abject-oriented practices.

via Simon Willison’s Weblog

Posted on
by

Over the years, I have been in many meetings where someone will ask an engineer how difficult a particular technical problem is to solve. More likely than not–after a lengthy question and answer session–the answer will be something like “hard” or “trivial”. Most people in the room will respond to this question with a befuddled look. The silence in the room will eventually be broken by someone demanding to know preciously what date this problem will be solved by.

If you are one of the befuddled on a regular basis, you should read Understanding Engineers: Feasibility. It offers definitions for these common engineering answers. Knowing this information might prevent costly assumptions in the future. For example, you might get excited when you are told a problem is “trivial” to solve. You might think that you can have this trivial solution tomorrow or next week. Perhaps you should think again:

The only caveat is that triviality refers to how hard the problem is to solve, not how hard it is to implement the solution. So there is no necessary relation between a task being trivial, and how long it takes…

For those readers that are already familiar with these definitions, you might want to forward this link to people who need to understand them. This might be especially useful before a difficult status meeting. Even better, perhaps you can persuade your project manager to print a short summary on the back of all meeting agendas.

via Simon Willison’s Weblog

Posted on
by

Fog Creek Software has an open house every year in their beautiful offices. But, even though I used to work right across the street, I missed it every year. This year will be different, I’m actually going to make it this time. If you are a technical type in the area of the West 30’s on Tuesday Thursday, the 19th, I suggest you do the same. The details are at joelonsoftware.com.