Software Engineering Week 5 - People Solutions

Week's notes

The focus for this week was on interacting with others and the importance of reviewing each others code. Based on the reading it seems like the agile process supports better code review than waterfall. The ideal code review seems to be around 60 minutes long for around 3-400 lines. Weekly short code reviews allow people to find errors without getting burnt out. If your development cycle is based around 1 week intervals with review and refactoring going on then there probably aren't going to be huge new chunks of code that you haven't reviewed any of before. That seems ideal for maintaining code quality. 

Aside from code review there were tips on how not to offend people and make things go smoothly. This doesn't sound like as much of an issue to me because these things work themselves out. If somebody is really terrible with people then they probably have some kind of social disorder. On the other hand they could just be rude. Ideally they have some kind of social disorder which you can figure out to become great friends with them. If the problem is that they are just rude then you won't end up working with them. Recruiting and management should factor those people out before they cause too much trouble. So advice on working with difficult people isn't really that great unless you're trying to be a salesman. The best advice for "working with difficult people" is to avoid organizations with poor management and recruiting so that you don't have a terrible day. Otherwise you are wasting your time and health.

In the background the homework continued learning about interesting Java technologies with applications in certain commercial fields. I'm still trying to get all of this going. MySQL is setup and I can use the workbench that came with it to load up a basic table. The problem I am running in to is related to running the JPA program that actually connects to the database running on my local machine. It's also still a bit tricky keeping track of how all the different Java things link together, what they need to run, how they all run, etc. The technologies seem useful though and established as a standard way to build applications. It does seem like a good deal of repetition and study would be needed to utilize the whole Java webapp route. 

  

Looking forward

Moving ahead we are ramping up on our group project. A basic repository is setup and game frame work is being built. The big trick here seems to be getting going. It is important to get a working base going that we can grow off of. Without that base then you could end up in a bit of a traffic jam having everybody trying to do the same thing. So I look forward to us branching out this week and then selecting and hitting targets with our project management software. 

Software Engineering Week 4 - Don't get hacked and do your homework

Week's notes

This week was pretty good. It feels like it is a bit slow for me to absorb the information but I enjoy the current course material. I am trying to learn a lot of new things in different areas at once so that can make my learning velocity feel like it isn't good enough. This week settled some problems for me by focusing on being device independent so I can do my work anywhere. I can have a different device for software development, design and documentation, and use other devices for course assignments like this. 

 As far as learning for this week, after trying out a few different programs for making UML diagrams my favorite is a google docs plugin called draw.io diagrams. The important thing for me is that I can access my files from any computer running windows, Linux, or chrome OS. That way I can spend more time on my course work. When things are locked to a single platform or require software installed on every device then that puts a wrench in things for me. 

Aside from process improvement there was some good reading this week comparing hacks of Sony and Target. The important thing for me from these articles is that inside the designer facade of a companies brand there are just people working at their computers. Every company isn't filled with super hackers designing their systems. Sometimes people just want to buy some software from Microsoft and get things up and running. Then they end up getting their systems broken into and lots of account information leaked. 

I don't fall into the category of people who say this is inevitable. If somebody is really motivated they can hack any system right? If the system is well designed then it gets harder though. Exploiting software and protecting against unwanted software use it isn't an area I know much about though. The important thing for me to keep in mind is what I don't know with regard to security.  By doing that I can work to avoid setting up critical systems without consulting experts. Also by utilizing known libraries when possible instead of getting creative with security schemes I think I can help to avoid introducing new opportunities hackers. 

Upcoming work

The exciting part for this week is ramping up our group project. Thanks to the selection of the Agile process for this project we can really make something fun. By having the project open ended and with a short weekly cycle of design/develop/deploy we can make something interesting without stressing out too much. 

Software Engineering Week 3 - UML could work out

Week's notes

The focus for this week was running into problems with a bunch of Java technologies to prepare for our upcoming group project. If we ran into these basic problems in week 5 then we would be out of luck. Instead we should be able to make a deliverable over several iterations. This week by making a hangman game with servlets and jsp files we demonstrated the key pieces needed to build a web app as a team. Key problems included loading two resources types from the server to display in dynamic pages and saving different game states per user. User input was also included but that was in earlier homework so not super critical.

UML  - A bunch of different types of diagrams with one language

At first glance it might seem like UML is going to be some niche way of making software diagrams, like using google drawings or custom drawing apps. Before you know it maybe you're up and running trying to make diagrams with UML to solve problems without knowing what's really up. That's how I felt until seeing that UML could be really useful. The surprising part to me is that there are so many diagram types that are all written in this language. Until today looking at these diagrams I wasn't sure what was going on and a little frustrated when new diagrams that claimed to be UML looked so different from each other. I think this is due to a resistance to be sold on a new keyword or language until it settles in. 

Design Patterns - they have some names

Remembering the names of design patterns seems pretty tricky. My interest is in the shapes that you see in software and matching the patterns to have a clean flow. So I look forward to studying more of these shapes and looking at sample design patterns. 

Software Engineering Week 2 - Test it all

This week I had some problems that threw me off a bit. So I didn't submit anything really. I did learn a lot from the reading and videos though. From those I can tell that big waterfall style software projects are not really my interest. Listing out how everything is going to work seems like a job for a different personality type than mine. What I like to do is lay out close targets for what can be done and then figure out where to go from there.

An example would be writing a piece of software to test an electronic device. Instead of getting all worked up planning the test software my first order of business is going to be making sure that I can control the instruments needed to interact with the device. This would result in needing to get GPIB and ethernet control of the devices working. With that doorway open I'd move ahead and lay out a few more close targets to hit until I reached my goal.

I can see the case for using things like UML diagrams though. Instead of using them in a waterfall process it would be nice to share them as google diagrams and update them as the project goes on. We will do that in week 4 I believe as we ramp up our team project. Normally I just try to keep these kinds of diagrams in my head as I work on a software project. Laying them out on paper seems like a good way to keep everybody on the same page though as we collaborate in a group format.

The emphasis on test was also interesting this week since I have worked in manufacturing test for a while. Having a test for just about every single piece of your program really seems to make sense but I haven't worked like that before. It reminds me of working on a poorly documented electrical cabinet for a test system. When I was first deployed to work on this large cabinet I wasn't sure where to start. Then someone told me "just trace every wire" and I thought they were joking. Sure enough, I went ahead and spent weeks tracing every wire to every electrical component and documenting it on a new schematic. This seems a bit like the test route where we should really have tests written for all of our code. At first my reaction is "really, every piece??" but it makes sense. The availability of automated test suites that can run through your tests makes it appear that this would actually pay a good dividend in the end. So long term I would like to follow along with this and figure out what the proper automated test route is for a given software development environment, Java or otherwise.

So this week I lagged due to some personal problems and I might fail but that's OK with me. The important thing is to just keep at it and learning new skills. Every repeated class gives me even more time spent reading and solving problems. I don't mind being a bit slow or scattered as far as my thinking goes as long as I can build interesting things.

Software Engineering Week 1 - Off to a good start

Week 1 - Off to a good start

There's lots of different people in the world so starting a new class is always interesting. The great thing about this class is that the way it is being run makes sense. There's no weird stuff, no tricks, things are just laid out in a way that looks well designed for student skill growth. What are the key attributes that appear so far which lead me to believe this?

1) Course content available early - If you are disorganized like me and only looking to focus on critical tasks as they pop up it is important to have as much information as possible. A friend once told me to ask the question "what happens if you do nothing?" as a metric for task priority assignment in a resource constrained environment. With more information available I can find key targets that can be hit early to prevent stress if

2) Consistent forum posts leading to e-mail updates on my phone for core assignment road blocks - In a class like this there are going to be generic problems that everybody runs in to. The instructor and TA in this class seem well aligned with the tools at hand and quickly respond to growing problems early enough during the assignment week for resolution.

3) Open ended assignments - This is a critical attribute that seems to appear in well run art classes. By leaving assignments open ended there is room for people to focus on the areas of a problem that are inspiring to them. As an example in an English class of mine there was extra credit for making a video about a writing topic. So I went ahead and produced a short cartoon on my computer, loaded it on to a VHS taps, and played it in class. The other students weren't sure what to make of my cartoon with a dinosaur eating people but the skill growth was there for sure. Similarly in a software class like this there is room to throw in a cutout of a dinosaur or anything that makes you happy and doesn't mess up your agile schedule.

There are still plenty of ways to mess this up for sure. It won't be because of poor course structure though. Personally I look forward to seeing what cool projects people create within this framework over the coming weeks.