They told me in my CSCI-1275 Systems Analysis and Design course there's a tendency for programmers to just start coding stuff without thinking, and this was nigh on tantamount to total catastrophe.
I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials.
(That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...).
At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. And then realized that my logic didn't properly deal with coefficients that were fractions. And that when I had terms being subtracted instead of added it behaved weird. And then if I only had two terms it straight up threw an exception about not finding an index. Basically, out of all the homework problems I was using as test data my program solved two correctly.
If the math parts were hard to follow, don't stress. The point you need to take away is that I wrote a program that did exactly one thing, but the test data proved it actually needed to do several different things. I had failed to take into account all the use cases my program were going to be called on. At first this wasn't such a serious issue--I found something that needed to be added or adjusted, and I did it. But as that cycle kept repeating, the program became ugly, confusing, and finally reached a point where further additions just weren't practical.
I had to blow it up and start from scratch, almost two weeks after first spinning up my first class.
It clicked--had I known the full extent of what I needed the program to do, all the use cases to take into account, I would have saved so much time. I would not have had a program dividing polynomials nearly as quickly, but I would have had a fully functional program far quicker and without the headache of constantly hacking new functionalities into it. Because of the lost time, I wasn't able to fully wrap up the application to my satisfaction...something that just doesn't cut it in a real world setting.
I would need to learn this lesson a couple more times before it really sank in, but you can bet you tail feathers I'm not starting anything like this project without putting in the time to determine my use cases. Results of that analysis to follow...
I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials.
(That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...).
At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. And then realized that my logic didn't properly deal with coefficients that were fractions. And that when I had terms being subtracted instead of added it behaved weird. And then if I only had two terms it straight up threw an exception about not finding an index. Basically, out of all the homework problems I was using as test data my program solved two correctly.
If the math parts were hard to follow, don't stress. The point you need to take away is that I wrote a program that did exactly one thing, but the test data proved it actually needed to do several different things. I had failed to take into account all the use cases my program were going to be called on. At first this wasn't such a serious issue--I found something that needed to be added or adjusted, and I did it. But as that cycle kept repeating, the program became ugly, confusing, and finally reached a point where further additions just weren't practical.
I had to blow it up and start from scratch, almost two weeks after first spinning up my first class.
It clicked--had I known the full extent of what I needed the program to do, all the use cases to take into account, I would have saved so much time. I would not have had a program dividing polynomials nearly as quickly, but I would have had a fully functional program far quicker and without the headache of constantly hacking new functionalities into it. Because of the lost time, I wasn't able to fully wrap up the application to my satisfaction...something that just doesn't cut it in a real world setting.
I would need to learn this lesson a couple more times before it really sank in, but you can bet you tail feathers I'm not starting anything like this project without putting in the time to determine my use cases. Results of that analysis to follow...
Comments
Post a Comment