More Developers, Less Code 10
Cat.: Then they fight you...14. August 2005
Why is it that when any institution has a need for software, they immediately start looking for pre-built “solutions”, instead of consulting a team of developers? Is it because that management feels that it will be less expensive to buy a “turnkey” software product than to pay developers to do the job right? Or is it that the higher-ups are looking for a stronger chain of responsibility if something goes wrong? I would assert that the real reason is somewhere in between the two.
Many of us have worked in houses whose primary business is something other than software. Our jobs ranged from being a one-man (or woman) IT department to simply being that person who picks up the phone when a user calls the helpdesk. In any event, if you’ve worked in this environment, it will quickly become clear to you that non-technical management seems to be its own worst enemy. I’m not saying that all management is bad, just that when it comes to making decisions about technology, a person’s self-importance can be their undoing. Software developers, we are guilty of this too. We put on a smile for the managers, when secretly we think to ourselves how much smarter we are. This attitude only pushes the divide further.
With such a sharp difference between IT and management, it’s no surprise that there is an internal conflict when it comes to making IT decisions. I’m going to describe a scenario that took place at place I had previously worked. This place is an educational institution, with a fairly reasonable IT budget. There are 2 people on staff in the IT department, both of whom are able programmers, with skills concentrated in dynamic web applications, namely PHP. We’ll call this place “the Institute”.
For years, student grading at the Institute was done by pencil and paper. At the end of every term, each teacher would tally up all his students test scores, and issue a grade. Once all a student’s grades were tallied, a small team in the registrar’s office would type up report cards on a typewriter, sign them, and mail them out to the parents. One copy of the report card was kept in a file cabinet, and the only method of access control was a key, having 5 copies, distributed to people who would need access to the information. Times were simple, and everything seemed to flow smoothly.
The Institute had been buying computers in small lots for quite some time. They were distributed sparsely - in the library, in the academic offices, and in the classrooms of teachers who managed to get themselves some kind of priority. Slowly but surely, an IT sprawl was occurring. The Institute saw it fit to hire a small IT staff - 2 people. Both of them young men who really had a passion of technology, and who liked the idea of growing their own infrastructure from the beginning. Eventually, the Institute had computers in most classrooms, a library full of PCs, and even a computer lab that students could drift in and out of in their spare time. The IT staff had been setting up a Microsoft-centric shop, because that’s what the management wanted. The two of them didn’t complain too much about it since the job was still fun, and Microsoft clients and servers seemed to work pretty well together - despite the occasional hiccup. Nothing a reboot couldn’t fix! There was server space and e-mail for everyone. Again, times were good.
There was one problem that nagged the IT pair, though. Grading was still being done with pencil and paper. The higher ups had started to catch on, too. We could make things so much faster if this was all done by computer. By this time, every teacher had his/her own laptop, and some had even taken to doing their grades in Excel - which sped up but didn’t unify the process. With this problem at hand, the IT staff started drawing up plans for a grading system. It would be a simple web application where teachers could enter test scores incrementally throughout the semester, grades would be tallied, and report cards could be printed. It could simplify the whole report card process to a single batch job. They had estimated it would take 6 months to develop and test, with another couple of months for small modifications and training. They could write it in their spare time, considering most of their day was comprised of reading Slashdot between taking support calls. The best part of the whole deal, though, was that it would all be free. The entire framework for the program would run on Open Source software, and since the management already paid the IT staff a salary, there would be no overhead for development.
The management, however, was less than receptive to this idea. When it went down, who was responsible? Who could they call for support? If it took 6 months to develop, wouldn’t we be in action faster if we just bought a “turnkey solution”? IT pleaded with the management to be more reasonable. If it went down, IT would support it. That, after all, was their job. A 6 month development time was a fine wait if it means you’re getting a good piece of software. The managers, though, decided to press on. They decided on a piece of software that had first come as a free sample in the mail. It cost $100 per workstation. IT, suspicious of any software that arrives in the mail unsolicited, reluctantly installed it on all of the faculty laptops. At first, the faculty was excited about this software, but then the questions started to roll in. Why can’t I import all my old grades from Excel into it? Why does it crash when I do X, Y and Z? With the animosity growing between IT and management, the IT people were not as responsive as they should have been when it came to answering user support calls. They were upset that the management had gone behind their backs, and wanted to exact some punishment. Management, on the other hand, was upset that their shiny new $5,000 investment wasn’t the silver bullet that ended all their problems. After a few heated meetings between IT and management, it was finally agreed upon that the Institute would look for a new electronic grading system. The highest authority at the Institute a well-educated fellow named John, had recently come back from a demo of a software product that would supposedly give the Institute electronic grading in one fell swoop. It was a custom-designed program that ran on Filemaker: the pseudo-database. John had loved it, and this was what the Institute was going to use. It was not open for debate. $25,000 later, the Institute had a Filemaker system. The sales force had convinced the Institute to not only buy the software, but a brand new dual-processor server as well. IT gritted their teeth as this new system came online for the first time.
Of course, the Filemaker system wasn’t compatible with the previous program, so teachers had to once again re-enter their grades. Another problem that IT foresaw but was unable to do anything about was the issue of access control. In days past, there had been 5 copies of a key to the file cabinet where all the grades were kept. Management, used to this concept, was very receptive to the idea of a single password for the whole Filemaker database. The IT staff knew it was only a matter of time before this password got out to the students, and sure enough, they were right. It took a month for the students to start changing their grades.
Amidst this crisis, IT pleaded with the management again. John, however, wouldn’t budge. He had made the decision, and it was final. Filemaker was it, and it was IT’s job to fix all of the problems. The teachers had lost their trust in the software, and started doing their grades in Excel again. The administrators, knowing that the students had gotten access to the database in the past, didn’t trust the software either. At the end of every semester, the teachers would e-mail their grades to the registrars, who would combine a student’s grades into a report card, written in Word. They would print 2 copies of this report card. One to mail to parents, and another to put in the 5-key file cabinet. After this process was complete, they would enter the student’s grades into Filemaker, but only for “archival” purposes. And so it remains to this day at the Institute.
The moral of this story is twofold: IT and management need to cooperate on a new level, and for internal software, roll-your-own is almost always superior to shrinkwrapped. Internally developed software is better suited to the problem than anything you can buy, and it humanizes IT more than purchased software does. To know that the software was made for the company, by the company gives users a much better attitude about using it, as long as it is done well. All that needs is for IT and management to trust eachother; something, I think, that will take a long time to happen.
