Sunday, December 18, 2016

Software Engineering Week 8 - The end

Course Summary

This course was a solid stream of software engineering concepts and applied work. There are two major takeaways for me:

1) People matter, a lot.
A theme that our instructor worked to get across was that people trump process. I am personally attached to the agile process because I do not know what it is like to work for people with high levels of planning. My career has been spent in small startup companies and generally chaotic environments where we design and deploy as quickly as possible. So that experience has probably misled me to believe that the process trumps the people. Generally I have been lucky to work with good people though. If I hadn't had such great people to work with then the process wouldn't have made things better.

In this class I was lucky to be assigned to a friendly and positive team with a good outlook. They communicated with each other and were not quick to get offended. So we could propose changes to the design, implement features, and work together without a lot of friction. This class was short and so was the team project but that only reinforces the point that people matter, a lot. With the wrong people this could have been a very negative experience due to the opportunity for stress presented by the timelines involved.

On the other end, the instructor for this course is highly focused on individual development. That aligns with my personal interests. I don't actually care what grade I get in any class, or if I pass, although that is a bit of a hassle. There isn't an end to learning for me and I could learn a lot if I had to retake this course. The problem for me would be taking a course with the wrong instructor and classmates. After all, people trump process.

2) Time spent on design is time saved programming
I have never been a heavily design oriented person. Generally I hack my way to success and figure out what needs to be done as I go along. This process presents a problem though: to scale up and delegate tasks to other team members I need to focus on learning the skills needed to share design ideas. UML for example is a great way to create a variety of diagrams that can convey your vision before work begins on a project. As work continues you can update these diagrams so the team has a shared vision. Without enhancing my skills in this area I will be limited in the complexity of projects I can engage in.  Software design is a core area for me to work on long after the course is over.



Tuesday, December 13, 2016

Software Engineering Week 7 - Getting Organized

Week's notes

This week was mostly about moving along on the final exam. I broke that up into a few nights to have time to think about things and go through the problems. It took a good amount of time to make things nice and there was a lot I didn't know before taking the test. Java interfaces for example was something I hadn't looked at much before. Interfaces provide a nice way to follow a pattern for your classes and the best article I found was on tutorials point of course. They seem to have the best info out there. The reason I had to look up interfaces was because of a question about using a publisher/subscriber pattern. The big thing I know about pub/sub is MQTT, a protocol for publishing and subscribing messages. 

Aside from the test I need to get back on our team project. We stopped before doing our first refactor. Without moving the gamestate out of the main game loop we can't call ourselves a view/model/controller based program. So there is some more work to be done on that. I still haven't figured out JPA and how to get Java to work with MySQL though. That is my big concern for reaching assignment criteria, but more importantly for doing something interesting. Getting a good grade is less important than learning how to do interesting things. 

Tuesday, December 6, 2016

Software Engineering Week 6 - Getting Organized

Weeks Notes

This week was about getting our project up and running, deployed online, and managed with pivotal tracker. One team member took a clear lead in developing the base software for our game. I scoped out what was going on and updated pivotal to see where we could go next. It was a fun week for sure but a bit stressful. My concentration has been on the team project and not really on gannt charts which was another topic for the week.

The content about gannt charts makes me happy to have friends who enjoy project management. I hope to continue to work with people like that and avoid this kind of organization as much as possible. In contrast this pivotal tracker program for Agile projects is really fun. It is nice to set goals for the week and be able to comment on them or move them around with ease. That kind of project management is no problem for me.

Using Pivotal Tracker and figuring out how to compile, debug, and upload the style of Java applications that this class uses has us at a nice start. Things are almost over though so that isn't great. I would like this class to be twice as long and have more fun with our application but that isn't reasonable because of the way this program is setup. The alternative of attending classes in person isn't an option for me either though due to work. So I think the 2nd best, and most expensive option is to just take classes like this a few times so I produce usable products.

Looking ahead

I still haven't been able to get a local JPA application working with MySQL. So that is the big problem for the next week. If my team gets it working on the server that is fine for the project but I need to be able to duplicate anything locally. By being able to run, debug, and modify the program locally I can do a proper code review and provide useful feedback for where our software can head during the next iteration. We also need to do a refactor to get our software away from everything running in the main Java applet. It would be ideal to have the applet handle the requests but have game objects that keep track of game state and let us have a game loop off to the side.