Derek noticed that there was no exit for a match, so he added a break to the loop. A request to go back to the old program was denied, as “the data conversion was permanent.” Derek decided to take a look at the code.Īfter spelunking through the depths of the program, he found a for-each loop going through a collection to look for a matching item. Late shipments meant unhappy customers.Ĭomplaints were sent out, but the crack engineering squad from the larger office sent a global message stating that they had investigated the code, that “there was a lot going on under the hood” and they would be unable to improve the speed. Losing that much time meant people were working overtime to get orders out, and some of them were going out late enough to miss the shipping deadlines. Everything these staff members did was dependent on getting the data ready to use. With the new program, running it two or three times meant two or three hours. With the old program, two or three cycles of fixing the data and rerunning the program were usually required, taking about an hour in total. Needed to be run again (so much for progress). It took over an hour to run.Īfter the program finished reconciliation, they found mistakes in the data that needed to be manually corrected and the program Just two months after the announcement, the new software was delivered, and it actually had the promised feature: manual fixing of data was no longer required! But there was a new problem. Derek's team members cheered and waited with bated breath. ![]() The larger company announced plans to create a new version of the program one that would eliminate all the manual data fixes. While the program itself only took around five minutes to run, those manual fixes ended up wasting about a half an hour of everyone’s morning. It had originally been written in a language Derek had never heard of, was error prone and required manual fixes to the data before it could be run. Most of the staff used a custom application to assist in this endeavour. His team was in charge of processing and shipping whatever was sold each day. However, a resourceful engineer can always turn it around, use the rules to his advantage, and defeat the machine!ĭerek K's company was a small branch of a much larger company. Common sense and rational thought have no place in the process. Sadly, you also tend to get people whose sole purpose is to ensure that everyone complies with the rules. It's enough to suck the life out of any well-meaning effort. The rules start to resemble a mindless automaton, blindly forging ahead, without thought, sensibility or sentience. #2, and whether you should choose one ply or two ply. You get stuff like instructions on whether of not to put a space before a semicolon in which corner of the page a staple should be used, and at what angle it should be to the page, or how many sheets of TP to use for #1 vs. ![]() People start clarifying rules to add finer grained detail. Unfortunately, beyond a certain point, the company becomes bureaucratic, and the folks making the rules tend to be insulated from the bigger picture. For example, coding style guidelines, if done correctly, can be a good thing. Eventually, it reaches critical mass, and all of these rules get quantified into written guidelines. Over time, the staff grows, and more rules are created about how this or that is to be done. As they figure out how the business is to be run, they come up with their own ways of doing things. When a new company is formed, it's usually just the owner, possibly some partners, and a small staff.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |