Forums
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:
Aug 14
Got anything for me to do?
Got anything for me to do?
Got anything for me to do?
...
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.
Devan was hired to support several legacy systems that were fraught with manual processes. A large part of his job was to find the numerous manual tasks that could be automated, and figure out ways to automate them. One of the systems he inherited allows a support person to query a set of special records for the prior production date, and update a subset of them by changing a certain date field, so that they'd be considered special in the production run for today.
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.
Documents for architecture, detailed design specifications and development guidelines were written. Specifications for defining major interfaces and mocking up external systems (e.g.: databases, web services, etc.) for unit tests were written up, each with specific examples of what library to use, and how to use it to perform a given type of test. It was even explicitly stated that no external system was to be accessed from unit tests; everything was to be mocked. Real testing could be done in an integration environment.
Although we're professionals now, we all started out as humble students - wide-eyed and innocent of the ways of proper coding practices in the corporate world. Back then, everything was new, and we had no real way of knowing whether what we were looking at was wizardry or WTF.
When C. T. was still in school, he ran across a routine for validating dates. It was written in lowly assembler. He found it fascinating, and spent a great deal of time examining its innards. It was designed to run on a 32-bit machine that lacked multiply or divide instructions. It also did something else unusual for the day: it worked on four digit years.
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.
Rob worked for a company that brought in three consultants to do a major rework of their database structure. One of them was being paid about $85 an hour for the sole job of filling out and maintaining a Microsoft Project schedule for the project. The first thing the consulting team did was put together a proper schema diagram of the database to be reworked. Then they tracked down all of the code that wrote to or read from each table. Armed with all of this ammunition, Mr. Project was able to put together a project time line.
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)
"We need to put foreign keys on auxiliary tables in order to enforce the relationships between primary and secondary data." We don't need foreign keys in the database; they slow everything down and make it harder to delete stuff. We'll just keep everything straight in code!