KIX Iteration 1

| No Comments

´╗┐With the start of this semester I never planned on talking this class. I am currently a Computer Engineering student and this class wasn't required for me. I ended up signing up for this class last minute as a way to avoid missing out on $1000 in financial aid. I figured that will my years of experience programming industrial automation, robots, HMI's, PLC's, PAC's and mountains of other obscure equipment, "why would I need a class like this." This class has been a nice change from other classes, giving the closest to real world experience you could get from a University. So this removal from a highly academic setting to something more useful in the short term has made this class interesting and helped to make me reconsider majors.

The project that we are currently working on is a compiler, written in C++ and with the idea for the language being one of programming parallel processes. This was great news for me for two reasons, my early programming experience is with Pascal and Karel which are two coding languages much like C++ and then my 1901 & 1902 equivalents were taught in C++; I am very comfortable with the language. The other part is that parallel computing, in general, has been an interest of mine and any reason to do projects about it sounds good to me. The project is going to be done in the iteration method, which I look forward to seeing as all my experience is in using the standard engineering development process. Often called the waterfall method, the engineering process has been often wrought with setback in my experience do to the volatile nature of coding but that same nature is what often attracts us who love coding to it. So, the opportunity to use a different method intrigued me and I look forward to seeing if this project proceeds better.

The other part of the projects implementation is that it will be done in groups of 2. The partner I chose was my girlfriend, for better or worse, due to our history of working on other smaller assignments. The hope with this choice is that due to our un-candid comments on how the process is progressing will help us better code. I much prefer straight answers and, thought we may fight about coding a lot, the whole process helps us to better understand the code and sometime come up with better code. The other part is she is able to put up with me in general which is always a plus as well. From here the project has been broken into 5 major iteration; first being a scanner.
For this iteration Jessica and I decided that the primary goal for our code was to make it clean and flexible. We wanted to be able to easily switch or move our data between structures with ease if needed and keep the classes well defined and encapsulated. The clean and flexible code would follow from well defined classes that have overloaded operators to allow for ease of use. Understanding that this can cause the code to become a bit larger in size and that the code may not be quite as efficient; we feel these benefits are worth it. Due to this being an iterative process, having flexible code can make it easier to adapt to changes and add to the overall reusability of the code. To aid with this we used the Standard Template Library to assist with keeping the code clean and flexible. The nice part about using this set of structures and functions is the consistence in their use, ability to easily change data between structures if needed, and it has been optimized for speed.

This decision posed some challenged after seeing the initial requirements and the need to interface with defined functions that had a different method for strings and lists. We understood that this was taken from old C code but wanted to still use the features C++, even if it was going to be extra work. Why would you use a higher level language, just to use the base features? That's like buying a house to sleep in the garage which made no sense to us. Our solution to this was to make the code work with our initial plan, then modify the tests to test our code implemented the way we wanted. Next, after we had tested this code to work we would create an interface functions that would allow for the old code to work with our code and allow the tests to work with ours.

Upon starting the project, my partner ran into serious family issues. This was something that is a real upset for a project, but has happen on other jobs I have worked on before. All you can do is help the person out in a time like this and work harder to help them out. So with this iteration, much of the work ended up being done by me which is not to reflect on my partner. There are many problems with doing most of a project by yourself which make it a terrible way to do a group project. The best part about working with others is the code is viewed by multiple people. This can help to simplify the code and make sure the extra work isn't being done. This happened when working on part of the code for identifying key syntax in the code. I ended up adding extra function to do the work of cleaning up text for ease of processing. The extra code I added wasn't needed and was added due to my lack of understanding of the code given by the instructor. This wasn't realized until the day the project was due but with the help of someone looking over the code and needing your ideas explained to them, all can help identify problems before they get to a point like this. The other major issue is that after one person mainly sets up the code, you have to take the time to then explain it all to them. This issue is normally avoided if you just divide the work up among functions and classes. When you have functions to work on, all you have to do is document/comment the interfacing to each function well and then the other people in the group can just pick them up and use them. If you need someone to go through your function though, you have to explain your thought process and try and convey what each part is doing. This can become a long and tedious process due to others thinking differently and having different coding styles that are equally as clean and efficient as your own. So after all of this, there isn't much that can be changed for the next iteration other that starting earlier. When a major family event that requires the attention of your partner comes up; all you can do is buckle down and pick up the extra slack.

The other issue was that we didn't utilize the test coding as well as we could. Through most of this iteration, the tests that we used were both bare minimum and written after the code. This was troublesome for multiple reasons. First, when we had the test code given to us by our instructor, it was easier to figure out what we needed (on a side note, the commenting on what was needed or for the function headers supplied in the files was terrible. I know the idea is for us to view the tests to tell what we need but you should also practice the good commenting practices you preach!). The test code helped guild what was needed and helped move me over the hurdle of figuring out what to do next. I didn't write the test cases before coding the tests for any of the helper functions that I created though. This is unfortunately how I would code when I worked and I believe that due to the crunch of having the extra work; it became a mode I fell into. I fell into a lot of the bad habits I formed during a time when a co-worker of mine on another project began to have seizures in the middle of a plant floor during a double startup that we had. We were both working 10-12 hour shifts to try and catch up on the project due to falling behind. The stress of the job and large amounts of sugar and caffeine got to him and his body eventually snapped. He was fine but the work got shifted to me, which was fine considering the circumstances, and I ended up working 16-18 hour shifts, 7 days a week, for a full month. Coding in situations like this cause you to start becoming more automated in some of the coding tasks that you do, all for the goal of just getting the task done as quickly as possible. This situation was not anywhere as bad as that but due to there being a crunch; old habits die hard and tend to rise up in situations like this. I ended up not commenting code I wrote as I wrote it, I would add lines and lines of extra code to test out code and then just comment it out, and I would just start blindly coding items and coming up with solutions on the fly just to try and get code on paper and get things working. This terrible combination will, and always has, add extra work in the long run and make it hard if not impossible for someone else to come in and help you work. This became obvious at the end of this iteration when Jess tried to help me finish the project the day it was due. She would be lost on trying to troubleshoot my code and I would have to try and help her understand it or end up having to do it myself. This is not due to her being a bad coder at all; on the contrary she is an extremely good coder in her own right. No, this was due to no comments, extra lines of code added in for testing, but not labeled as such, and to little or no time to explain the code to her. Overall, this iteration left much room for improvement on my part since that is the only part that can be controlled. As for my partner, I can only hope that things get better for her and with that the project can proceed better as well.

Not all things were done terribly on this project; the one part that went well was sharing of files. This was my first time using a version control system and I can now safely say I don't want to work on another coding project without one. Throughout the project Jess and I have used the SVN software extensively as a means for sharing files. This has been great as it just takes a simple command to share the files and allow for us to always have the latest code. The issue of conflicts with code hasn't risen up due to a constant communication back and forth about what we have been working on. We have a program to help with conflicts if they arise as well called Beyond Compare which is an excellent program for checking for differences in files and allowing for quick and easy merging of files. With the combination of these two programs we haven't had any real issues to speak of as far as sharing files and keeping up to day with each other's changes. This has been a bigger improvement over previous versions of file sharing that we have tried to implement in past projects. We hope to keep this level of communication and sharing up as well due to how nice it has made coding and its ability to not interfere with our momentum while coding.

For the next iteration we know we have a lot to improve upon. For starters the code needs to be cleaned up and optimized better due to the fact it was hamstrung together to meet the deadline. Extra tests for the code we have would be nice and writing tests before new code is implemented is a must. I will be trying to comment before and while coding to try and help facilitate understanding of my functions and I'm sure the comments of my code already there can be improved upon. The one thing that would be nice to try for an improvement would be to try and find a good IDE that can interface with SVN. I believe that this could help speed up development to have some software help manage the file structure for us and make it easier to upload files; not that uploading need to be much easier. These improvements will be the main goal of iteration 2 and I feel that they will help its development flow better. I will let you know how that goes after we have finished the 2nd iteration.

Recent Entries

Find recent content on the main index or look in the archives to find all content.