Who is a software engineer?

We've discussed in class what it means to be a software engineer and the meaning of craftsmanship, but as was brought up in the last class, how do you know that someone is qualified to be a software engineer? Software engineering certainly does not have the same certifications and regulations that ME, EE, or CE fields have.

Typically, hiring companies require that you have a degree in CS or software engineering, but this is not always the case. At some companies (which shall go unnamed), having a master's degree or PhD holds more importance than having a degree in the field that you are working in. For instance, I know a person with a master's in ME who is working on developing complex code in VB and C# but they do not understand object-oriented programming or the basics of testing and debugging software. I know another person with a bachelor's in EE who wrote thousands of lines of analysis code in Java but did not understand how to properly use try-catch blocks, report exceptions, or utilize some more basic object-oriented design principles.

Yet, these people are considered "software engineers" even though, if they had to take a certification exam, they probably would not pass. So, I guess I can understand why having standards or, though I hate to say it, regulations, can be important in producing readable, commented, well-designed code. But, at the same time, I cringe at the thought of the miles of red-tape that will be produced once some sort of unified software engineering "certification" is standardized. Anytime a regulations, committees, and certifications enter a field, it becomes a headache for anyone wanting to make that their career path. However, when you look at some of the software glitches that have cost people a significant amount of money (or released prisoners early), it is understandable why people want the standardization and certification. And when I see people "coding" and "designing" software who do not know the first thing about basic testing, debugging, and design principles, well, let's just say, it is a cause of great frustration for me. And it probably will be for you too because you know that one day you'll end up having to use that software, or, even worse, add features to it.

Software Design Patterns...there are a lot!

So, I knew that there were quite a few software design patterns, but I'd never really looked at any of them in great detail. The basic concept behind a software design pattern is that it provides a template that can be followed in order to solve a certain problem in a given situation. In essence, they are best practices that are implemented by the developer. Apparently there are software design patterns for everything from algorithms to structural design. As mentioned in class, these patterns are to developers what blueprints are to builders. They guide the developer in creating a program that will hopefully be better because it is based on a pattern that has been tested, used, and has been proven to improve the software structure and help prevent certain problems and issues from arising.

Obviously, a developer can't just choose any software design pattern since each is best suited for specific purposes (for instance, you probably wouldn't want to use a Monad design for an object-oriented project). Thus, it is up to the developer to choose the design that best fits their program and inappropriately choosing a design could harm the final project by introducing confusion and complications.

A problem with using a software design pattern also comes from the generalization of the design. The design cannot be too specific or else it will not work for majority of applications. Thus, the design has to contain some abstraction (or indirection as Wikipedia mentions) in order to remain flexible. This can introduce complications into the resulting software because of misunderstandings about how to implement the abstractions and can cause performance issues with the application.

I picked out a few of the patterns mentioned in the article to discuss here.  The Interpreter pattern was especially interesting to me because I had to create an interpreter and parser for a calculator in a previous class. The Interpreter pattern basically provides a framework for interpreting a computer language (or something as simple as interpreting reverse polish notation). Each symbol in the language is given its own class (and it does not matter whether the symbol is terminal or not) and this class defines how to interpret that symbol. For instance, a Number class's interpreter function would return a number while a Plus class's interpreter would return the sum of it's left and right operands. I essentially used this method when I created my calculator, but I did not know that it was an actual design pattern. The pattern is helpful in that it provides a basic structure for creating the interpreter for a language, which can then be combined with a parser.

Another pattern that I looked at was the Decorator pattern. This is essentially a way of standardizing wrapper creation for a class. For instance, you have a class that has almost all the functionality you need except for one or two operations or components. In order to add this functionality, you create a decorator class which would extend the original class (or interface) and take the original class as an argument to the constructor. The additional functionality is added to this object once it is passed into the decorator class. As the example in the Wikipedia article shows, you could have a Window interface, subclass it into a WindowDecorator interface, which takes a Window as the constructor's parameter, and then further subclass the WindowDecorator to provide extra functionality such as scrollbars. This makes it extremely easy to add or remove features from a specific object without having to create ridiculous subclasses such as MyHorizonatalVerticalScrollBarBorderedWindow. 


I also looked at the Wikipedia article "Software Design Patterns" in order to find a more complete list of such patterns. Browsing through them, I recognized some templates that are used in the coding languages that I use. For instance the "Hollywood Principle" is used in the Enterprise JavaBeans framework. The idea behind the Hollywood Principle is "Instead of your program running the system, the system runs your program." Basically this method allows the programmer to focus on creating the application without having to worry about all the system calls that happen behind the scenes. In essence, approaches that use this technique will provide a framework that the developer must follow and build on. This is helpful in that it allows the developer to focus on the specifics of the application being built, but it could also be restrictive or time-consuming if you have to create functionality that is not necessarily supported by the framework.

Ideal team in 3 words

In 3 words: responsible, motivated, creative. I have worked on teams in both work and school situations and, honestly, I almost always dread it. Inevitably, the team suffers (and therefore the project suffers) because one or more team members do not want to work, habitually submit work late, fail to communicate with others, or expect others to fix problems with their code/report/spreadsheet/etc... Sometimes these issues are explainable because of interference from other commitments, work schedule, etc. However, in general, I see a trend where a few group members do most of the work. To me, those 3 words mean:

1. Responsible: showing up on time, making sure their code is tested and well-documented, and willing to own up to their mistakes and learn from them.
2. Motivated: taking the initiative, going above and beyond the minimum requirements.
3. Creative: contributing ideas and suggestions that will help the project improve and finding solutions to problems.

I think a team composed of members that can at least generally adhere to the above three descriptions will be able to accomplish their project goals and be able to improve on the original project concept.

Three other words that I would have included if I could: hardworking, detail-oriented, and honest. Having a team that is hardworking is important for getting all the tasks completed on time. This could also be interpreted as a willingness to work since, without that, very little would get done. I know "detail-oriented" is probably a completely over-used term, but I feel it is an important characteristic of any good programmer since you not only have to look at the "big picture" but you also have to pay attention to small things (tweaking code to make it better, performing thorough testings, etc.) that are also important to the overall success of the project. Finally, having a team that is honest is also a key attribute in my mind. By honesty, I mean being straightforward in communicating with others and being willing to report any problems. Any team that lacks honesty is going to suffer from issues that arise when members refuse to voice their thoughts or refuse to report a problem when they first see it. Any of these things could cause a setback in the project with regard to both time and money.

Proposal Reviews

I reviewed the proposals from Kevin, Sonny, and Ben and the PDFs are accessible through the links below:

Ben:
https://drive.google.com/file/d/0B4jV0EcSqqGGNDdCWmZlUlB1MTg/edit?usp=sharing

Kevin:
https://drive.google.com/file/d/0B4jV0EcSqqGGQVV6SXBKZl9XUWc/edit?usp=sharing

Sonny:
https://drive.google.com/file/d/0B4jV0EcSqqGGTE9HUmMxcXg1VmM/edit?usp=sharing

Software Craftsmanship

The first thought I had when I read the first two sentences of the Wikipedia article on Software Craftsmanship was "Agile!". And, sure enough, three sentences later, the article mentions the Agile Manifesto. Clearly, based on this article, developers have started to favor an approach to software that is more people-oriented and flexible (like Agile) and have even begun viewing software creation as a "craft", much like in a medieval guild.

To me, the term "craftsman" describes someone who creates things (anything from software to buildings) and takes pride in producing a product that is high quality. In this sense, I think any engineer, not just software engineers, are craftsmen. Engineers build or create things that help better the world (or at least a small piece of it) and any good engineer will take pride in producing a quality product. However, the Wiki article seems to imply that engineering (though not necessarily software engineering) is not a craft because it has a more mathematical and analytical (read, "stricter and more rigid") approach that requires licensing and certification.

I am somewhat torn about this view. On one hand, I can see how regulation and inflexibility can remove the person from the equation, thus removing the essence of "craftsmanship." On the other hand, just because there is licensing and regulation does not mean that engineering is not a craft. Medieval guilds were essentially a form of licensing--i.e. if you were a member, you had been trained in that guild's craft and were expected to follow certain rules. The article seems to imply that because software engineering does not have these restrictions, then it can be considered a craft while engineering in general cannot. I certainly think that the greater flexibility and few restrictions in software engineering mean that it is easier to pass on knowledge, but as far as skilled crafts go, software engineering is not the only engineering discipline that requires skill, practice, and some amount of pride to perform well in.

Reflections on creating a project proposal

Since I finished the first iteration of my project proposal, I thought that I'd talk a little bit about the process of creating it. This was essentially the first proposal that I'd ever done. It was certainly a different experience creating a proposal when I'm used to being the one that just gets told, "here's what we want, now go code it up." I found that even though I had an idea for my project, actually thinking about what would need to be done to create it was a little more difficult. It really forces to you contemplate the pros and cons of every approach and try to figure out which approach best suits your "vision" of how you want the project to take shape. I think the parts I struggled with the most were the specification requirements and the budget (though the timeline was a little tricky too since I was not quite sure how much detail to include). For me, the specification requirements were harder to write because I was not sure how "in-depth" I should get with the details of the system. Obviously, I don't want to lock myself down into doing something only one way, but I also want to provide enough detail so someone reading the proposal will have a general idea of how we plan to create the website and how all the parts will fit together. I also found the budget to be difficult since I have never had to price out a project. I've created budgets for personal use, but creating them for a project is an entirely different animal. I did some research on how people create project budgets and the advice that seemed to keep reoccurring was just to practice. Essentially, the first time you do a project budget, you're not going to know exactly what should be put in the budget or how much "padding" to include in order to offset problems and delays that arise. However, once you've done a few budgets, you start understanding what you need and the process becomes easier.

I feel that I've learned a lot from creating this proposal, though I know that I have a lot of room for improvement. Receiving feedback on it will be very helpful in order to show me what I've made mistakes on and how I can improve. Hopefully this means that the next iteration of the proposal will be a little more straightforward to create.

Link to Project Proposal PDF

Uploaded the PDF of my proposal to my Google Drive and the link for it is below:

https://drive.google.com/file/d/0B4jV0EcSqqGGdng2YWFpdnRGbGM/edit?usp=sharing