Birth Reflection

"I want you to reflect back on that JOURNEY in this final Journal Entry.  Feel free to point back to previous journal entries....but try to provide a few paragraphs that summarize your overall experience in the CS 3750 and CS 4750 courses.  What will you take away from this experience, regardless of the ultimate result of the where the project ended up?  If you could go back and do 3 things differently, what would they be?  Finally, are you proud of your "baby", or do you want to give it up for "adoption"?  Be honest!"

This is what we're supposed to reflect on in this journal post.  My overall experience...  hm...  I feel that I have grown as a programmer; I have learned some new problem solving techniques and have refined some old ones.  I have learned a fair amount about myself also over the course of this project.  I've learned that I tend to be a visual learner, and that I tend to think in a procedural manner.  This isn't necessarily an asset for a Software Engineer.  I think Software Engineers need to be more abstract than procedural thinkers, and it's better if they can learn by reading something than seeing it done; however, I know I'm not the only one in this position.  I may not be the sharpest tool in the shed, but I don't think I'm a hammer either.  

I will take away a lesson from this experience about working as a team, or group on a project.  I tend to not have a lot of input when it comes to the framework of a project, and that's because I realize that I probably don't know best, and I'd like to learn what's best from someone who I consider to be more knowledgeable than myself.  That can be a problem if I think I'm getting somewhere or learning something, but really am not.  I need to be able to take a step back and look objectively at what I'm doing.  I consider myself to generally be pretty objective about things, and I think that when I get into a project, that objectivity tends to go away with regards to the project.  In other words, I believe I get tunnel vision when working on something and can't really see the whole picture.  That's a problem, as we saw in this project, because I was so focused on my end of it, that I wasn't able to see how Dan and Bryan's parts interacted with mine.  

If I were to go back and do 3 things differently, I would first of all go with a .net framework.  I think that using asp.net could have made this project go more quickly, it would have contributed more to real world experience, and it could have made a more maintainable project, I feel.  I don't really think I would change anything else.  I think changing the framework would take care of a lot of the problems we've run into.  Bryan has had a lot of trouble with the MySql database, I've had trouble with the jQuery.  I don't know if Dan has had any problems with the PHP, but I know that he likes .net, and would probably have been happier working in it.

Am I proud of my baby?  Yes, I think that this is a very worthwhile project, and I am glad to be a part of it.  I believe it will be useful to PARC when it gets done.  I have a personal goal of getting a product that they can beta test before the end of the semester so that they can play with it over the break.  I will be prioritizing my other classes, and will work on this project as time permits.  

In summation, I have learned quite a bit over the course of this project.  A lot about myself, and a good amount of coding.  Especially jQuery, which I had no knowledge of prior to this class.  I am grateful for the group I was able to work with, and wish them all well as they continue in their education or as they move on in their lives.

Reflections

Haha, well, we didn't get done with the software for a beta release.  It's looking like we may not finish the project by the end of the semester either.  I'm disappointed to write that, as I really want to get the project done.  If it happens that we don't get the project done by the end of the semester, I think I'll continue to help as much as possible to try and get it finished.

Reflections on the software engineering experience...  it is a difficult process, but rewarding when you see something come to fruition.  I have seen the ui develop, and have been able to build it from pretty much just empty accordions into something that looks and feels like a professional web application.  I have enjoyed seeing this project develop, and have really enjoyed getting the ui to pull from the db to display information that has been entered previously.  This is probably a trivial thing, but it took us some time to get there.

We've still got a long way to go.  I've finished the UI except for some very small things, and now I'm working on a client object that will hold all the information the interviewer enters and then send it to the database when it's done.

We may be closer than we think, or we may not be.  I'm hoping we'll be able to at least give PARC something that will allow them to enter clients and retrieve them as needed so that they will be able to use it for data entry.  The reporting is Dan's deal, and he doesn't think it will be done by the end of the semester.  The database is complete, I believe, and now it's just a matter of interacting with it.  Parc has requested a print feature that I don't think will be hard to do, but I don't think it will be done by the end of the semester either (maybe the next class?).

I enjoy software engineering.  I think that were we professionals and in a situation where we could have worked on this project 8 hours a day, we could have probably knocked it out in about the length of one semester.  Since we're students though, and there are many other demands on our time, we weren't able to do quite as much as we thought we were going to.  Alas, but this has been a great experience, and I wouldn't trade it.  Thanks Dr. Fry!

This week has been really, really difficult.  Trying to get the alpha ready has really been incredibly time consuming.  I think we all thought we were further along than we were.  I'm sure I've written a few thousand lines of code myself, and have gone over well over 10,000 lines.  Our Page.js file has kind of gotten huge.  It's bigger than Dan thought it was going to be, or he would have broken it out.  We still may end up doing that.  I have noticed a lot of code repetition in our project, and; looking back, can see where we could have done a lot of things differently.  Sadly, it's too late now.  I suppose this is stuff we should have caught in the development phase, but we didn't.  So now we're testing!

Testing is tedious.  I realize that it's a necessary part of any program development process, and that doesn't make it any easier.  It's particularly so when you're testing someone else's software and you want to be working on your own.  One of the things I like about doing web programming is that its so instantaneous;  that is, I test all the time when I'm developing a web application, because it's easy to do so.  Just hitting the preview button in your IDE or the refresh button after you've saved some changes will instantly show you what you've done.  With the new browser's bug editing features, it's even easier than it ever has been.  So testing is something that I do constantly during the development process, and having to to it explicitly, just on it's own, is not my favorite.  Even so, it is nice when something you've created gets tested and is found to be working.  It's also nice to get a list of things that don't work and be able to correct them.

I'm hoping that we will be able to correct all the problems that the Camper World group is finding, and before the deadline for the Beta.  This project has turned out to be larger than any of us anticipated, and I still think we can complete it before the semester is out.  Again, it would help to have a fifth person, another programmer, but not having one won't make it impossible, just difficult.  I hope you'll keep our diminished group size in mind when grading.  ;)

Team Environments

What is the importance of working in a team environment in a software engineering project?  It's my opinion that teams are extremely important when doing software engineering.  I find, personally, that when I'm working on a project, I tend to get to certain points that are like plateaus.  I hit them, and I just kind of get stuck.  It's very difficult to get past these plateaus on my own.  It's not impossible, but the level of effort required to get past the "block" is generally prohibitive, especially since most projects I work on individually are personal.  I do have some assignments at my job though, currently, and I have hit the plateau on one, and am having a hard time with the other.  I'm working on these projects individually.

I find that when there is a team involved, other team members can quite easily push over a plateau, helping me get back on track.  A lot of times, they have ideas that I've never considered, or a piece of knowledge that I haven't yet gained.

I used to be big into body building, and it's similar there.  If you don't have a partner or at the very least a spotter, you will not be able to push yourself, and you won't be able to progress as rapidly as you would be able to if you had a partner.  Partners can push you and help you to get past plateaus.

I think it's cool that Google employees work in teams, and that they do peer reviews for raises and promotions.  I like that it encourages an atmosphere of support and teamwork.  I like peer reviews, and as we've been doing them in this class, I think they've been good.  I think they might be more effective if we received the results of our peer reviews whether we want to or not, though I know that makes more work for the teacher.

I think software engineering is a team sport.  I believe that it is much easier to complete a project, and much faster to complete a project as a team; even just a two person team can make a huge difference.

What's gonna work? Teamwork!

Sooo... What do I know about teamwork?  I will start off by saying that this team that I'm in now,while not perfect, probably has the best teamwork of a team that I've had here at WSU.  I've had pretty good teams, and some really bad teams, and this one just seems to gel really well.  I'm glad I was able to get the team that I have.

I think what makes this team work so much better than teams I've had in the past is that everyone WANTS to contribute; to have a hand in the success of this project.  In other groups that I've had, everyone wanted success, but not everyone wanted to contribute to that success.  In this group, it seems that everyone is willing and eager to get their hands dirty, if you will.  I think part of that is the maturity level of our team; I think we're all non-trad students, with the possible exception of Daniel, so that might be what the difference is.

I have been a supervisor before.  I supervised about 13 people.  It was my responsibility to make sure that my people were trained (continuous training for new procedures), and that morale was good.  It was my responsibility to ensure quality on my shift.  It was also my responsibility to enact and enforce policies on my shift.  The number one thing I learned from this?  I don't want to be a supervisor.  I don't want to be a team leader.  I don't want to be put in a position where other people are subordinate to me, no matter how shallow the levels of the organization.  The reason for this is that I have very high expectations of myself, and I have a hard time lowering these expectations when it comes to others.  In other words, I expect my subordinates to have as high expectations of themselves as I have of myself, and that is almost never the case.  Some good advice I got one time said, "unmet expectations lead to frustration."  How true!  So I am perfectly content to be a cog in a machine.  I don't need the recognition, good or bad, that a leader receives.  That may sound unambitious, and it is, but my priorities for success lay outside the realm of work.  As long as I can provide for my family in a moderate way (we don't need to be rich), then I'm happy.

You ask about teamwork as it relates to software engineering - I would say that it's very important.  Communication (interpersonal) is very important when working on something that can be as abstract as software.  You must be able to convey your ideas to your colleagues.  It has happened to me several times that I would suggest something, and apparently not convey the idea well enough because then someone else says the same thing differently a short while later and everyone is wowed.  It's interesting when this happens to me; it causes me to reflect on how the other person conveyed their idea, and I try to learn from that so that in the future, I can communicate more effectively.

Another thing you ask about is conflict management.  I am a big believer in not being a baby.  That's about all I can say about that.  I like to be dealt with honestly and I deal with others in the same way.  If I don't like someone, it doesn't mean I act like a child about it, it just means that I do my work and let them do theirs and call it good.  I don't believe you have to be buddies with someone in order to work well with them.  I do think it's nice when that happens, but I don't think it's something that is entirely necessary.

The last thing I will touch on is managing stress.  I am still working on figuring that one out.  It seems to help me that I have one day a week (Monday) that I don't have to worry about homework or the kids or anything, and I just do what I want to do.  I look forward to that Monday's quite a bit throughout the week, and often spend a few minutes a week planning for that day.  I usually spend Monday nights with some buddies playing games, and it's a nice release.

That's it for now.  Hope that works!

Initial Post

This is a blog that our professor has asked that we keep over the course of this semester.  I am terrible at journal keeping, so I'm sure this will be a bit of a struggle for me.  :)

The question has been asked, "What is the best way to think of software development?"  Here are my thoughts on the matter:


Software development, in my opinion, is using software to meet a customer or clients needs.  The development process consists of interviewing the client and using pointed questions to try and determine their needs.  This process takes time, and over a period of time, the requirements will become more clear.  It's important to continue to ask questions and really get down into the minutia of things to really see what the client is needing.  I think of software development as a refinement of a process to make it as streamlined and efficient as possible.  This idea can be carried over to things other than creating software as all.  


Some things I have learned over this last semester are that the only way to really understand what the customer wants is to develop psychic powers, or to do their job until you are an expert at it.  Since neither of these options are very feasible, it's important to make sure that the interviewing process is maximized, and that communication is constant with the client.  The client needs to see what you're doing in order to determine if you're on track or not, and you need the customer to communicate this with you so that your view of the final product becomes more and more clear.  


Bryan has been the primary point of contact in our group, and I imagine that he's got a very good idea of what the client is looking for.  Bryan communicates this information to us very well, never the less, he should intrinsically have a deeper understanding, as he has been speaking with the client the most.


So, can this be taught in the classroom?  I would say that the fundamentals of this can indeed be taught in a class (if not the classroom), utilizing several techniques.  This class and 3750 have been a great way of introducing this idea to students.  Another way would be to have the teacher act as the client, including some specification changes and what not.  


I don't think that communication with clients is a requirement for a Software Engineer to get a job; however, I do think that if you are able to communicate effectively, you will be an infinitely better software engineer, and are much more likely to get and keep a job.  I also think that being able to communicate will greatly increase your marketability as a software engineer.  I have heard of several people in the CS department taking a communications minor, which I think is a good idea.  I would probably do that, but I don't have time.  :)


I hope this is a satisfactory post, and will meet the requirements the professor is looking for.  I guess we'll find out!