Delivering a project and presenting to a multi-level audience


Image: Acting in theatre and delivering the end result of your project are not too unalike. Image taken from

A great acting coach once told me, “The problem with most young actors is that they act. They don’t do.” What he meant was that the key to a good delivery is simply delivering, focusing on who you are delivering to (usually your scene partner), and not getting caught up in your own self and how you think you look. The same concept can be applied to delivering a project to potential consumers. For many great presenters, such as Steve Jobs, this would mean relentless practice. If the content you were showing off was not second nature to them, they would retreat inward, attempting to think their way out on the spot. One chink like that is all it takes to ruin your delivery entirely. Steve Jobs never exposed himself to such a simple mistake, as people within Apple claim “Jobs rehearses the entire presentation aloud for hours” (Gallo, 2008). This is also just a simple rule of acting: no good actor goes on stage without knowing his lines like the back of his hand well in advance.

Furthermore, to “do” and not “act,” you have to have genuine feeling behind everything. Audiences are great at telling when a presenter is not genuine, even if they don’t consciously realize it. Jobs is a great example of a passionate presenter, “using words like ‘extraordinary,’ ‘amazing,’ and ‘cool'” (Gallo, 2008). While it seems contradictory to rehearse your lines to death yet also maintain genuine passion, those who are truly into their own work generally still end up excited about it after the hundredth rehearsal, and Jobs was clearly no different. Furthermore, having rehearsed your content so much leaves room to inject the presentation with your own personality on the fly, and that’s what really sells. People love listening to people, not presenters, and certainly not bad actors.

A brilliant presenter eloquently makes all the specs and numbers mean something to the audience. A blanket number of 4 million, while high, does nothing for an audience on its own. Steve Jobs, however, would add on to that sales number, saying “That’s 20,000 iPhones a day, on average,” and then go on to display how that number compares to the competitors, driving home Apple’s dominance of the market share (Gallo, 2008). While people have a somewhat innate sense for non-genuine speakers, not everyone is a math whiz, and even fewer are computer whizzes. Thus it only makes sense to connect the dots for your audience.


Image: Steve Jobs, not only a brilliant innovator, but a brilliant speaker and performer. Image taken from

While there is a definite technique to how Steve Jobs made his presentations stand out so much, at the end of the day, there is no substitute for hard work. In the case of Jobs, this meant hours upon hours of “preparation, rehearsal, and criticism” (Rogers, 2009).


Gallo, C. (2008, January 25). Deliver a Presentation Like Steve Jobs. Retrieved December 1, 2014.

Rogers, G. (2009, December 9). Preparation is key to effective delivery. Retrieved December 1, 2014.


Handing off a project to a client; what are the risks and challenges?


Image: Handing off the project.

From previous blog posts, you may have learned new information about the Agile process. But what about when all is said and done? Like many other aspects of development, the handing off of your project could make or break the overall success. Perhaps the project didn’t make time deadlines, leaving one small, crucial step unfinished, or maybe the documentation is unclear, leaving the product owner unable to use the finished product properly. There’s several ways the project as a whole can be ruined, so it’s important to not burn out towards the end.

For starters, how will the product owner learn to use the finished project? What level of detail do you need to provide? Too little or too much will simply cause confusion and frustration, ultimately lowering the satisfaction and quality of the end result. Next, what medium will be used to deliver the product? If this is not made clear, the end result can be delayed or even jeopardized if said medium ends up being unreliable.

Ultimately, these risks can be minimized during the course of the development cycles as well. Westfall defines six types of risk “technical risks,” “management risks,” “financial risks,” “legal risks,” “personnel risks,” and “other resource risks” (Westfall, 2001). These risks can be defined as the following:

  • Technical risks include but are not limited to “problems with languages, project size, project functionality” and other tech based aspects of the project (Westfall, 2001).
  • Management risks essentially mean lack of planning or communication leading to the project devolving into an unorganized mess.
  • Financial risks include going over budget or having issues with cash flow.
  • Legal risks include changing legal requirements, any relevant health hazard the project could pose, and liability or warranty issues.
  • Personnel risks include not having enough team members, lack of relevant experience,
  • Other resource issues can range from lacking computers to poor response time from key individuals to poor quality tools.

The obvious way around all of these risks is to simply identify them as a possibility, make a contingency plan, and execute it if necessary. A more detailed explanation can be seen in the flowchart below.


Image: A general plan on how to handle risks (Westfall, 2001).

Assuming you avoid these risks before they come up, all that you really need to worry about is handing the project off. While it may be a project that you consider your mental baby, author Tom Peters claims that though it can be hard to do, “people who have what it takes to create Wow Projects rarely have what it takes to operate those projects” (Peters). Ultimately, it’s highly likely that the project would not only be better managed by someone else, but you came into the project knowing that at the end, it would no longer be yours, but instead the product owner’s. But with that said, there is good reason to celebrate! You and your team have finished what’s either one of your best works yet or something you couldn’t wait to have off your hands; cause for celebration either way.


Peters, T. (n.d.). The Wow Project.

Westfall, L. (2000). Software risk management. In Annual Quality Congress Proceedings-American Society for Quality Control (4)(pp. 32-39). ASQ; 1999.

What Five Technical Skills are Employees Seeking? What Soft Skills Put You on Top?

While there exist many heated discussions on online forums about which programming language is the one to rule them all, the topic is a lot more complex than such forums would have you think. Many languages serve different purposes, with no one language truly being better than all the others in every way. With that said, certain languages clearly have an edge over others in terms of finding a job, stability, or popularity among elite programmers.

One method to telling the the numerical approach. A software research firm known as TIOBE have created an index to help gauge the popularity of various languages, and “the analysts produce an aggregate index each month” (King, 2011). Thus, the numbers help give an impression of what the most popular languages are among several sources in real time. Not surprisingly, Java, C, and C++ are among the most mentioned.


Image: A collection of language rankings gathered from TIOBE and

As shown in the graphic below, web-based languages seem to have the best luck in terms of finding a job. At least, that is what seems to be the case on Craigslist job postings. Among the most requested by employers on there are PHP, “a language used for Web development,” and SQL, a language “used for writing database queries” (King, 2011). A few notches under that is Javascript, which is primarily used in “Web-based applications that connect users to databases” (King, 2011). Google, a very high end employer, is partially responsible for Javascript’s recent popularity due to their web apps like Gmail.

But that isn’t to say these languages will necessarily last; according to Ritchie King, one notable quality of a programming language is “How established is a language?” (King, 2011) Many Computer Science majors, myself included, would immediately list off C, C++, Java, and perhaps Visual Basic as they correlate with what most college and university courses offer. Not surprisingly, these languages are also the ones with the most book titles about them, as the image also shows. This kind of thing does not happen by random chance. The ones writing these texts are those who were very experienced with the aforementioned languages when they were brand new, clearly demonstrating how they have stood the test of time.


Image: Several examples of soft skills. Some more useful to programmers than others.

Of course, not even knowing all the listed languages will guarantee you a job. There is still the additional “soft skills,” which can be broadly defined as “the cluster of personality traits, social graces, facility with language, personal habits, friendliness, and optimism that mark people to varying degrees” (Schulz, 2008). While soft skills are not necessarily mandatory, they are what separate good applicants from excellent applicants. Unless you plan on being a fully independent contractor/developer, you will want some people skills and other soft skills in your repertoire. According to Schulz, when most people think soft skills, the first thing to come to mind is communication (Schulz, 2008). While it is true that communication and several subskills of communication (body language, dialog, culture, etc.) are all important, that is not all that soft skills entail. For example, one soft skill that is of great importance to software developers is creativity; as programmers, we are problem solvers. Not every solution to our problems exist on the internet, and thus the best way to guarantee the best solution is to make it yourself. Other useful soft skills for developers include time management, project management, and teamwork capability. In my recent Agile project, I and four other students arguably gained more from these skills than any knowledge of web applications.


King, R. (2011, October). The Top 10 Programming Languages.

Schulz, B. (2008). The Importance of Soft Skills: Education beyond academic knowledge.

LibGDX: Game development made simpler.

If you have a great idea for a game you want to develop but find the whole process daunting, just remember that tools (and Google) are your best friend! One tool I have grown to love over the past year is libGDX, a Java development framework that allows you to simultaneously develop games for Desktop, Android, iOS, HTML, and more. Though there is some controversy over using Java to create desktop games, libGDX works very well assuming you are not trying to add AAA-title graphics into your game (Ahmed & Aule, 2011).

I personally believe this program is great for beginners to mobile development as it does not require an Android/iOS background to create apps (though down the line, it definitely helps). Similarly, you learn a lot about computer graphics working with the various libGDX graphic libraries, but it does not require extensive rendering or graphics knowledge (Ahmed & Aule, 2011). That is not to say that libGDX is only meant for beginners, however; with appropriate knowledge of OpenGL and platform-specific components, LibGDX can accomplish much more than make a simple game.


A list from libGDX’s website detailing some of its features (Zechner, 2013).

One of the greatest selling points of libGDX over other game development tools is that its ability to be cross platform allows you to test and debug your game through the desktop, regardless of what platform(s) you intend to release the game on (Ahmed & Aule, 2011). This means that, in the case of mobile games, you can bypass the need for constantly uploading to an Android/iOS device or, worse, running incredibly slow emulators. The input detection used by the framework considers touch screen input and mouse clicking to be the same thing, so there is no loss whatsoever in functionality. Obviously for platform-specific tools like mobile advertisements or Google Play Game Services (GPGS), you will need an actual device to test properly, but for just making sure that your core game runs as you want it to, using the desktop will more than suffice.


(Left) The Android version of my game, ColorSquared. Note the GPGS welcome message. (Right) The desktop version of the same game, used only for testing purposes.

Another important distinction between libGDX and other engines is that the former is completely free and open source(Zechner, 2013). In a world where much software is pay-to-rent, this is crucial. If you want to start developing for free and don’t mind the inferior 3D graphics performance compared to a tool like Unity3D, libGDX is definitely the way to go. On the other hand, if you are working with a team to create a 3D-heavy game for mobile and have about $100 you can drop each month on software, then Unity is probably preferable.

Overall, if you plan on making a game solely for one platform or are working with an incredibly GPU-heavy 3D graphics engine, there are probably better tools to use. However, the cross-platform functionality, ease of use, and great performance for what it offers make libGDX a very viable tool for any aspiring indie game developer.


Ahmed, R., & Aule, J. (2011, June 14). An evaluation of the framework Libgdx when developing a game prototype for Android devices.

Zechner, M. (2013, January 1). Goals and Features – libGDX.

LinkedIn and how to market yourself on a professional networking service.


Part of my own LinkedIn page.

More and more, people are finding that the job markets in many fields are becoming more competitive. Therefore, it becomes very important for prospective employees to take every step they can to set themselves apart from the crowd. Using Professional Networking Sites(PNS’s) is a key way to accomplish this (Jacobs, 2009). LinkedIn is the leading PNS globally, with over 300 million members and thousands of companies hiring directly from the site. And in addition to providing a means to find employment/employees, PNS’s are useful for a variety of other purposes, including:

  • Access to all professional contacts
  • A free method of establishing an online presence and your own “brand.”
  • Keeping up to date with industry trends.

Online networking is in many ways similar to in-person networking. The networker puts out their own information and expertise on a particular topic without expecting anything in return. For example, they might link their own source code on a site like GitHub, create tutorial videos on YouTube, or create posts about the field(s) they have experience with. In the case of networks online and in person, constant work is required to maintain it (Jacobs, 2009). A person cannot have no interaction with their networks for months on end, then approach them when they find themselves needing a job, for example. And as a continuation of the previous point, a network must be established before the one making it actually needs it. That is, making a network while employed is significantly easier than making a network after losing your job.

Developing an online professional network is a multi-step process. The first step is (logically) to set up a professional profile on a network such as LinkedIn. While creating your profile, keep in mind what kind of impression you want to give off and what your brand is, or what differentiates you from other candidates (Jacobs, 2009). Make sure you have your resume on hand so you can add relevant, important information. And ensure that whatever you post, you’ll want it to appear on a Google search, as there is no guarantee of removing information posted on the Internet.


A map showing the most common buzzwords on LinkedIn by country (LinkedIn, 2013).

The importance of making oneself stand out from a crowd cannot be overstressed. One easily avoidable mistake is using common “buzzwords.” LinkedIn released the most overused “buzzwords” in their users’ profiles in 2013 (LinkedIn, 2013). These words are:

  1. Responsible
  2. Strategic
  3. Creative
  4. Effective
  5. Patient
  6. Expert
  7. Organizational
  8. Driven
  9. Innovative
  10. Analytical

If you feel like you would want to use any of these words, the simple solution is to use an appropriate synonym. For example, instead of patient, perhaps use “composed” or “understanding.”

After creating your profile, the next step is to begin building your network. Many users begin by simply adding as many people as they can, but this practice is not only lacking professional focus, but it violates some basic online etiquette. With that said, however, every network begins somewhere. And it makes sense to start with your friends, classmates, and professional acquaintances. From there, the network can be expanded to include those that identify as “open networkers,” people who seek to build large networks encompassing a certain field (Jacobs, 2009). Lastly, you can also seek out recruiters for your field of interest, either contacting them when they have a relevant job opening, or referring them to other members of your network when they have an opening in their field.

While creating a LinkedIn network is important, users should also seek visibility on the site as a whole by participating in discussions, making blog posts, and just generally sharing knowledge and experiences. In doing this, be sure to always maintain good net-etiquette and treat every post as though there is no delete button.


Being Responsible is Overrated. (2013, December 1). Retrieved October 17, 2014.

Jacobs, G. (2009) Online Professional Networking. Professional Development.

Agile task lists and what “done” means in Agile.

As mentioned in previous blogs, Agile is a cyclical development method that begins with gathering User Stories. These team then identifies a few User Stories to serve as the product backlog for the leg of the sprint. From there, task cards are derived from each item in the backlog. These cards show the individual steps developers need to take to make the product fulfill each User Story (Ambler & Holitza). The task cards are placed on a board, arranged into an organized matrix used to display the overall progress on the current sprint’s product backlog. This task board makes the progress easily visible to all members of the project, from the developers to the product owner.


An example of an Agile task board, listing all tasks and their estimated completion time (Hughes, 2013).

The organization of the board is fairly simple, as seen above, but it remains effective nonetheless. Every User Story is shown on the leftmost column of the board, sorted by priority. Then in each story’s row, all tasks are organized by current status, as shown in the example image above. This method of listing the current tasks is advantageous over others as quality assurance is built into the process (Hughes 2013). Every task that gets listed on the board has to go through multiple layers of validation. For example, in the image above, a developer must first write a test, another developer must then use the tests, and finally, the product owner must confirm that every unit fulfills the business needs of the product. Additionally, the board provides a single, central focus to the team.


An example of a burndown chart. Left, a chart with perfect progress. Right, a chart showing some trouble (Hughes, 2013).

Though the task board shows an individual level of detail, it does not show a global, big-picture view of the team’s progress. That is where the burndown chart comes in. The burndown chart displays the estimated remaining hours of labor required for the current sprint. Ideally, this chart is progressing at a rate that will have it reach zero before the end of the sprint, like in the image above on the left. This serves as a good diagnostic tool for the team: if the rate of progress is not fast enough before the demo is due, it is readily apparent to the whole team and adjustments can be made immediately (Hughes, 2013). Ultimately, the sprint is “done” when the preassigned date arrives, regardless of whether the burndown chart reaches zero or not. Ideally, however, the graph will help to make the process more efficient and motivate the team to get more done.


Ambler, S., & Holitza, M. (2012). Agile For Dummies. San Jose: John Wiley & Sons.

Hughes, R. (2013). Agile Data Warehousing Project Management. Waltham: Elsevier.

What is an Agile Sprint Retrospective?

A very important part of Agile is the ability to observe and adapt to the unexpected. This is generally handled at the end of each Sprint during the Sprint Review and Sprint Retrospective. While the former focuses on analyzing the product, the Sprint Retrospective focuses on analyzing the process (Deemer & Benefield). The team, Agile Master, and Product Owner all discuss what is and is not working, as well as what adaptations could be made in the next sprint.


A sample image depicting the processes in a Sprint Retrospective. Image taken from

During each Sprint Retrospective, there is a list of activities that must be completed before moving forward:

1) Define the retrospective focus (Sepitani, 2014). The group determines the key points of the process that will be analyzed. The default focus is to simply review everything the team used in that particular sprint.

2) Select the exercises (Sepitani, 2014). The group picks exercises that will help them think, explore, and make decisions together.

3) Gather objective data (Sepitani, 2014). All hard data regarding the process is assembled, such as burndown charts. This data is used to create a clear image of how work was completed and at what rate.

4) Structure the retrospective (Sepitani, 2014). The retrospective needs to be prepared and finalized. Everyone then determines the place, date, and time that it will take place.

During the actual meeting itself, the members consider which development processes are working, which ones are not, and what changes to make for the next sprint. A simple method of doing this is drawing two columns on a white board: one column for what is currently working, and one column for what could be better. Individually, the team members go around the room and add items to either list. It is also important to note whether Agile is the cause of this problem or if it is exposing the problem so that appropriate adjustments can be made (Deemer & Benefield).

After that, the Product Backlog is then updated. Since some items have been completed, others changed, and others still dropped entirely, it is important that all items are reviewed and documented accordingly. These changes are then shown in the release burndown chart, showing the team’s progress towards their expected release date.


Deemer, P., Benefield, G., Larman, C., & Vodde, B. (2010). The Scrum Primer.

Septiani, H. (2014, January 1). Advanced Topics of Information System Scrum.