Feature Articles

« Aug 14

September 2014

 

Gridlock

2014-09-29
In every global organization, there comes a point where someone figures out that all of those servers scattered throughout the planet aren't running at 100% capacity, and that they are sitting there going:

Forever Alone

2014-09-24
Dan’s team had a large re-engineering project. They wanted to remove some Java dependencies and replace the UI layer with their new, in-house developed standard library. Like most large maintenance projects, it was big, had a few hidden traps, but was mostly time consuming tedium. For the tedious bits, they decided to bring on a new developer.

A Repetitive Task

2014-09-22
Everyone has had the displeasure of having to perform some mind-numbing repetitive task. Those of us who know how to program computers will use our expertise to figure out a way to get the machine to serve us by performing the menial task on our behalf. After all, computers were designed to serve us. The more mundane the task, the greater the urgency to automate it so we don't need to deal with the details any more.

Dropping a Load

2014-09-16
Bryan is a highly paid consultant in a position as a senior architect at a really big company. In the first part of his assignment, he concentrated heavily upon gathering requirements and designing a high-level architecture. In the latter part of his assignment, development tasks were thrown at the inexpensive offshore team.
John worked for an MSP with a broad range of clients. An hour after arriving home from work one day, he received a call from a local doctor’s office. Kelly, the office manager, barely let him finish his “Hello.”
Rebecca's first day at Mega Thrift Stores (or MTS) didn't start well. She was hired as an assistant to Maggie, the aging head of Quality Assurance, to handle issues and complaints from regional managers about their resource tracking software. Rebecca asked if they used Bugzilla.
Anyone with any significant amount of experience has had to estimate a project of some complexity. The only real way to do it is by breaking down the project into major parts. Then breaking each part into smaller parts and so on, until you have a list of units-of-work that you can reasonably estimate the amount of time that will be required to do that work. Then you figure in dependencies, see what can be done in parallel, factor in available staffing, add it all up, pad by as much as you think you can get away with to account for unscheduled changes, miscalculations, emergencies and management stupidity. Finally, you put it into a project management tool and make your presentation to the Powers That Be.
Gary works in a huge conglomerate. There are about 500 developers and assorted low level managers on his floor alone, and everyone is constantly on live audio-chat with their remote peers. As such, you can pretty much hear all of the conversations going on at any given time - if you listen... (see if you can guess whether the engineers or managers are in italics)
« Aug 14

September 2014