This happened in my second year MCA. Through some friends, Mr TM got to know of me, and he said that one of his relatives wanted to computerise his business. He proposed that he will take care of everything and I'd just write code. He could write code himself, of course, but he didn't have the time for it. So I agreed. By this time I had had some bad experiences with MS Access, so I suggested that we'd use MS SQL Server as the database. But TM wanted Access. I agreed to that. It was his project anyway.
Another thing TM was particular about, apart from using Access, was that we shouldn't be using any modern reporting solution. All reporting tools used Windows' GDI to print the report on paper. "We must do the DOS-style printing so that printing is really really fast", he said, though he wasn't sure if that was even possible. I knew in theory how that could be done from a Win32 program, and this was a good opportunity to verify if my guess was correct. So I agreed happily.
I defined my own reporting language and wrote a simple reporting system in Visual Basic. The reporting system would generate plain text reports, which I'd just write to PRN file. Worked like a charm. (Later, this reporting language grew to include bold text, right-, center-, and left-aligned text, page breaks, cumulative totals, and all such funky features. Even today, thinking about that system makes me feel good about myself.)
When it was mostly done, I showed him the working program and the reports. He was happy with the way report was generated and printed. He asked me how I'd done that. I showed him the report definition .rpt files and the report generator code. He didn't bother to see the code. Only feedback he had was that having individual .rpt files was bad because you lose one file and your program stops working. I had a solution for that too. I baked in all .rpt files into the .exe as resources so the program effectively needed only one .exe file to run. Again, he only wanted to know if I had fixed the problem; he didn't care how I fixed it.
He took a few days to use the app and see how it worked. He called me and set up a meeting. He showed a few bugs he had found. Then he gave the big news: the customer wanted to be able to keep some records "hidden" so that they don't have to pay taxes for all the money they were making. But having anything in the UI that suggests that some records might be hidden was not acceptable. Plus, the entire app needed to understand hidden records. Search, reports, etc. should or should not include hidden records depending on which mode the system was in. Effectively, there'd be two reports: one for the customer and one for the government. Requirement itself was fair, but the timing was not. I had to change the entire app to understand "white" records and "black" records.
It took a while, but I changed the app throughout to make it work. After a few more days of testing, the customer test drove the app for a few hours. That uncovered a number of flaws in the system that invalidated some fundamental assumptions the app was built on. TM asked me to make changes again. Without those changes there was no way the customer could use it, so we had no way other than changing the app to fit the new requirements. It went on like this for a while, with random changes suggested to every part of the system.
With all these ad hoc changes, the code was becoming worse day by day and the number of bugs kept increasing. What we thought would be a 2 weeks project was not complete after 3 months. I love coding so much, so I don't usually fix my price before starting the work. I hadn't talked about money to TM either. One day I asked him how much he'd pay me. He agreed to pay some 20% of what I had in mind. (He even paid me a part of it then, I think.) I told him that the actual work had been several times more than what we initially thought and demanded more. His response was that he can't get a penny from the customer before the program goes live and he can only charge what he'd agreed to before starting the work.
I wasn't happy. I told him that I can't work anymore and I came off. I really don't think TM could have understood the code and fixed bugs. The project might have been abandoned soon after I had left. He probably didn't get any money from the customer either.
Thinking about it now, I think TM's fault was that he didn't know what PM-ing was, and did a sloppy job of it. My fault, as a coder, was to trust the PM too much. Even when I hesitated to do certain things -- like coding some mother of all hacks -- TM encouraged me to do it. I think it was because he didn't understand the risks involved. I never bothered to make him understand either. (There's a reason for that: most people like TM look at how polite I am and conclude that I don't know what I'm doing. Even when I say doing something may not be right, they'll "encourage" me like "oh not a problem, don't worry, go ahead". One other person I have worked with knew I was good and he always respected my judgement. Not coincidentally, all projects I worked with him made it to production.)
Another thing TM was particular about, apart from using Access, was that we shouldn't be using any modern reporting solution. All reporting tools used Windows' GDI to print the report on paper. "We must do the DOS-style printing so that printing is really really fast", he said, though he wasn't sure if that was even possible. I knew in theory how that could be done from a Win32 program, and this was a good opportunity to verify if my guess was correct. So I agreed happily.
I defined my own reporting language and wrote a simple reporting system in Visual Basic. The reporting system would generate plain text reports, which I'd just write to PRN file. Worked like a charm. (Later, this reporting language grew to include bold text, right-, center-, and left-aligned text, page breaks, cumulative totals, and all such funky features. Even today, thinking about that system makes me feel good about myself.)
When it was mostly done, I showed him the working program and the reports. He was happy with the way report was generated and printed. He asked me how I'd done that. I showed him the report definition .rpt files and the report generator code. He didn't bother to see the code. Only feedback he had was that having individual .rpt files was bad because you lose one file and your program stops working. I had a solution for that too. I baked in all .rpt files into the .exe as resources so the program effectively needed only one .exe file to run. Again, he only wanted to know if I had fixed the problem; he didn't care how I fixed it.
He took a few days to use the app and see how it worked. He called me and set up a meeting. He showed a few bugs he had found. Then he gave the big news: the customer wanted to be able to keep some records "hidden" so that they don't have to pay taxes for all the money they were making. But having anything in the UI that suggests that some records might be hidden was not acceptable. Plus, the entire app needed to understand hidden records. Search, reports, etc. should or should not include hidden records depending on which mode the system was in. Effectively, there'd be two reports: one for the customer and one for the government. Requirement itself was fair, but the timing was not. I had to change the entire app to understand "white" records and "black" records.
It took a while, but I changed the app throughout to make it work. After a few more days of testing, the customer test drove the app for a few hours. That uncovered a number of flaws in the system that invalidated some fundamental assumptions the app was built on. TM asked me to make changes again. Without those changes there was no way the customer could use it, so we had no way other than changing the app to fit the new requirements. It went on like this for a while, with random changes suggested to every part of the system.
With all these ad hoc changes, the code was becoming worse day by day and the number of bugs kept increasing. What we thought would be a 2 weeks project was not complete after 3 months. I love coding so much, so I don't usually fix my price before starting the work. I hadn't talked about money to TM either. One day I asked him how much he'd pay me. He agreed to pay some 20% of what I had in mind. (He even paid me a part of it then, I think.) I told him that the actual work had been several times more than what we initially thought and demanded more. His response was that he can't get a penny from the customer before the program goes live and he can only charge what he'd agreed to before starting the work.
I wasn't happy. I told him that I can't work anymore and I came off. I really don't think TM could have understood the code and fixed bugs. The project might have been abandoned soon after I had left. He probably didn't get any money from the customer either.
Thinking about it now, I think TM's fault was that he didn't know what PM-ing was, and did a sloppy job of it. My fault, as a coder, was to trust the PM too much. Even when I hesitated to do certain things -- like coding some mother of all hacks -- TM encouraged me to do it. I think it was because he didn't understand the risks involved. I never bothered to make him understand either. (There's a reason for that: most people like TM look at how polite I am and conclude that I don't know what I'm doing. Even when I say doing something may not be right, they'll "encourage" me like "oh not a problem, don't worry, go ahead". One other person I have worked with knew I was good and he always respected my judgement. Not coincidentally, all projects I worked with him made it to production.)
No comments:
Post a Comment