On The Topic 1: Open Source (OBS).

Today we will be talking about the most used tool on Twitch. OBS. OBS is an open source software called Open Broadcast Software. Coincidence? I think not.

OBS was born as a small project on 2014 by Hugh (a.k.a. Jim) Bailey, but it picked up stream very fast, and suddenly it became a huge collaboration and it became vastly popular. On the same year, the development started and it became a powerful API. Right now it is working hand by hand with Twitch and it is one of the best screen recorders out of all.

As of right now, the software is not finished yet. Still, it is very used and promoted by major web sites.

The fact that it is open source allows everyone to be a video content creator and it promotes the use of other apps such as Youtube Gaming and Twitch.

Surviving at the Software Industy (12) - I'm Almost There.

Today we are gonna talk about starting the implementation of our project. We're done planning by now and we can start programming. Our movie for today will be the first contemporary Disney Princess, The Princess And The Frog. Tiana will join us as we develop our own project as she shows us the dedication she put on getting her restaurant.

Ever since she was a little girl, she saw how her dad wanted to put a restaurant on New Orleans called "Tiana's Place". Even when her dad passed away, she kept his dream as her own, and she put all her efforts to get the job done. 

The first thing we need is to follow our Software Development Plan. We already did it on earlier stages, and we shouldn't waste our effort. That was the guide we gave to our client, so we better stick to it. We can also reduce the risks of having low quality, lack of visibility or running out of time. It's not good to have a jar of coins without knowing how much money we have inside of it.

For our plan, it is extremely important we define some "milestones" or things we HAVE to do to maintain order over the general project, our lovely book recommends us to do the following activities on every project.

• Requirements updates 
• Detailed design 
• Construction 
• Test case creation 
• User documentation updates 
• Technical reviews 
• Defect corrections 
• Technical coordination
• Risk management 
• Project tracking 
• Integration and release
• End of stage wrap-up

Returning to the mini-milestones, these are activities that can only be classified on one of two categories, "done" and "not done. They have only two scenarios. Tiana shows us how this works.

Her first goal is to get the money to buy the place for her restaurant, then buy the furniture, then becoming a human again (you can't be 50% a human and 50% a frog), oh wait. This will help you to keep track of the project and to know how much of the project is done. If you want to, you can have a list of mini-milestones done so you can get inspired from that.

Also, one thing is to do stuff, and another thing is to do something good. You can check the quality of the product by making technical reviews. If your team starts missing their minor milestones DO NOT PANIC. It's actually pretty common this happens. You will have to pay more attention to the needs of your team and to be there for them to solve most of the problems rapidly.

There are different ways to manage a team, chose the one that adapts better to the way you are confortable with. It is important you don't feel awkward on the leading position, because you'd spread the awkwardness through your whole team. Remember, when you have all your plans on place, You're Almost There (yes, like Tiana's song).

The Class That Decided Not To Code.

The other day, I was on a group chat with one of my older friends from my major (ISC). We were talking about if I should go and play Overwatch with them or if I should study for my Advance Programming course exam. His girlfriend (who's also an ISC, and a friend of mine) told me that I shouldn't worry too much, because the exam would not be hard, and then my friend told her: but remember, they are the generation that decided not to code.

"What was he talking about?" You may ask yourself. Well, my class (2014-2018) was the biggest one since they re-oppened ISC in Campus Guadalajara. We were around 60 people and we were the half of the general population of ISC. Right now, we are 30-40 (if you include all the people from other generations who are taking less or more courses) and, it's true. We don't like to code.

It is bad to generalize. Of course there are A LOT of those 35 people who enjoy coding. From the top of my head I can think of 10 people who had told me "I enjoy coding", but at the same time I can tell you 10 more who have tell me the opposite. So you may ask yourself now "If these people don't like coding, what are they doing studying ISC? CODING IS THE BASE OF EVERYTHING!".

Well, don't get me wrong, we KNOW how to code, but we don't want to do it. It's like a doctor who doesn't like to do surgery. He/She knows how to perform one, but doesn't necessarily want to do one. There are many areas where a engineer can work, and even if coding looks like the base of everything, perhaps it's not.

This conversation with my friend got me thinking how much we put labels on each other. We are not only ISC guys anymore, we are "The ISC guys who don't like to code" and that just feels unnecessary and inaccurate.

We should appreciate all people, not just by what do they like or not. Our major is already one with the most labels on it, at least we should take those out from our inner circle to get to know everyone on ISC better.

Surviving at the Software Industry (11) - Let's Go To Paradise Falls!

We are on the last stage of preparation of our project! Isn't that exciting? I think it is. We just have to make our last preparations so we can roll. We will be talking about a movie that is none other than the second animated movie nominated for Best Picture in all history: Up. 

Carl and Ellie wanted to travel to Paradise falls to meet their hero. From the moment they got married, they had a can where they put all the extra money they had every day. When Ellie was a kid, she had planned how the travel would have been and she added some pictures and stamps to her book so she wouldn't forget anything. Of course, life happened and they had to postpone their trip for ever. 

I'm gonna skip the saddest part of the movie by talking about our last stage. As of right now we just have to estimate. We have to calculate how much time are we gonna take on every stage, our milestones the costs, everything. We already have everything planned and this is adding like a cherry to our milkshake. Everything has to look great on paper. I remember Ken told us once on our TI2011 course that if we wanted to estimate right we had to multiply our first estimate by two and then work on the next time unit. So if we would be taking 3 weeks on the project, we would actually be working on it 6 months. Crazy, right? Maybe just as crazy as making a house flying with balloons.

We also have to consider that we can't just escape on a flying property of the real work. We have to take in consideration other factors such as marketers, tendencies and sudden / unexpected changes. The best way to deal with these situations is by having a stage delivery plan. 

We have talked a lot about our delivery plans. I remember how people from ISC who are now graduates always told us that when we were on projects such as Taller Vertical, we had to ALWAYS have a deliverable. So, when we were thinking of building a flying house, we couldn't be preparing the balloons, the helium and the house from the beginning. We should start by having a flying bicycle, then a flying apartment, and so on. This process could be time consuming, but it is always best to do it this way. If we have a sudden change, we can go back to a decent stage and not starting from the beginning. It is also important to deliver the releases to our client, so they can see the advances on the project and mention if something's off.

Now we have to talk about risk and vision. Have we analyzed how safe it is to travel to another hemisphere on a helium-based flying house? I'm guessing not. We have to be sure that we are aware of the most risks we can manage and how would we deal with them. Our vision has to be our inspiration. It has to be clear and it has to help you and your team to keep moving forward on the same direction. If not, we wouldn't land on Paradise Falls.

By having an awesome and inspired team with our authority on the same line of thought, nothing is gonna stop us to find these lovely waterfalls.

Surviving at the Software Industry (10) - It's time to become a well-dressed devil.

I know I should be comparing this chapter to something related with construction and things like that, but I can't think of any movie that can helps me on that genre, so today we'll be using The Devil Wears Prada. This one is a fun movie to watch and it comes on Fox almost once a week.

As software developers we are condemned to become software architects. And yeah, we do a lot of stuff that architecs do when they are planning on building a bridge. We have to treat some issues on the same ways.

If a client asks you to do something in specific and they have a delimited budget and you cannot achieve it.

The client wants to know how the project is going on any stage. They want to be informed.

We have to fix the problems as soon as possible or it will be more expensive on the future.

And we all love coffee with all our heart.

So we can talk about the main characteristics of a good architecture now. The system overview is describing everything in broad terms so we can have a general idea of the project. It has to happen on a high level discussion. The conceptual integrity phase is where the objectives for the architecture are stated. This ensures that the architecture covers all the problems of the project, whatever it is. Subsystems and Organization is when you star defining the areas or subsytems of a project. It can be divided on the major clusters of functionality, or major areas of the general system. Although it is good to have some communication you cannot have everyone knowing every single aspect of the project. Is not convenient. Imagine if an intern listened a brainstorm meeting for the next season!

We have to have our team on the same page. It is important to define a standard notation for our diagrams and to be sure that everyone is capable of reading them. We also have to be prepared for change. If we see that something's about to change we can start to making preparations and we won't suffer as much when the time comes. If we see the trend is changing, we have to be faster as designers or we won't be relevant. If the weather is changing we have to get out of that city or we won't be able to see our families on time.

Reusing code is not bad if it is useful and does not affect the architecture. We also have to question our approaches, see if what we are doing is the right thing or if there's a better / cheaper way to do it. Then, we have to define the traceability and the delivery plan so our client does not desesperate.

The architecture will be complete when you can say without any problem "My file covers all these areas, I feel confident we can work this out."

Surviving at the Software Industry (9) - Caravan your way out of problems.

It's not a secret that I admire Damien Chazelle a lot. He is the youngest movie director of all times. Today we'll be talking his first big hit "Whiplash" on the context of quality. If you haven't watched this film I recommend you to watch it because it is gorgeous.

In the film, we have an abusive professor on a jazz school called Fletcher. This professor is obsessed with perfection and he aims to get the best students on his group to perform difficult jazz songs and to become a great school jazz band.

The chapter nine from the book talks about quality. What is good, the consequences of doing the job right and doing it wrong. It also helps you to see the big picture, and to identify all what is around of the making of a good project.

If we don't ensure good quality, we can end like Carl Tanner and being kicked out of the band. Sometimes the project wont be quite the client's tempo and they will need you to give them support on the project AFTER you deliver it. All of these problem are solvable on the early stages of the project. We just need a Quality Assurance Plan, or QAP, a fancy nickname I invented for it.

So, what should we have on our plan? The book gives us a list of concepts that we should be aware of when doing our document. Look at Andrew. He had to rehearse every single day and go over all his flaws to achieve his teacher's expectations.

• Defect Tracking: You can't just think that all your problems are gonna be solved by looking at them. You have to keep a record of them, if not, you are going to forget you have them and you won't solve them. Andrew went over the same 15 seconds of Caravan over and over until his hands stopped working.
• Unit Testing: You have to test. This step shouldn't be a secret by now. You have to join your drums with the rest of the band and to see how you're all doing.
• Source-Code Tracing: Going through all the lines of code on a debugger. If you do that you can see how everything functions, step by step.
• Technical Reviews: Go with co-workers and other people so they can give you reviews, and you can do the same with their parts of the projects. It is always good to have the insight from anothe human being, and then you won't be a loner drumer without a social life.
• Integration Testing: Mix all the code together, new and old, and be sure everything is working fine.
• System Testing: Now you can play Caravan right. You can start to play all together to refine the final touches.

As soon as you can master that you will be ready to play not only Caravan, but Whiplash and any other jazz song easily!

Surviving at the Software Industry (8) - How Far I'll Go.

Here's where a regular student who has not taken this class would normally start a project. You are right now in the same spot as Moana was when her grandma told her what she had to do to save Motunui. Don't let the sea take you by surprise!

As a project manager, you have to get the requirements for the project. You can get them in various ways, but they all are a little complicated. You can gather candidate requirements by interviewing and reviewing other products, but this could be like trying to talk with the Ocean. They think they know what they want and you think you understand them, but you have to be very careful so you can take the useful information.

Specifying requirements, or commiting with the gathered requirements to tangible media, like storyboards, this could be like talking to Mini-Maui, he is pretty expresive, and he can write and store all the information from his adventures. Finally, you can analize requirements, or breaking them to their essential characteristics.

So, what's the best way to get all the requirements? 

• Identify a set of key end users or defining who wil be using the system. You don't want an accelerometer on an app that will help you to cook on your house, or you wouldn't like to take a boat all by yourself if you do not know how to sail. Oh Wait.
• Interview the End Users, or actually make a first round of interviews. So you can see what is happening with your users. What do they think about it.
• Build a prototype, but it has to be a simple one. You don't have to be such a perfectionist. It just has to have the basic functionalities. It is very useful to record the results on paper, using storyboards and check the level of excitement of the users when the test comes to an end. Do you remember how excited was Maui when Moana learned how to sail? You have to wait and see if your prototype is actually working.
• Develop a style guide, after you have a functional prototype, you can start thinking on making the application cute. The grandma didn't make the necklace without having the heart of Te-Fiti. The guide shouldn't be very long, but it can help the designers to follow basic rules.
• Fully extend the prototype, this is the stage where you try to make everything better. the graphs, architecture and design work, interactions with other products, textual outputs, feasibilitiy study, architecture, etc. Don't forget this is not the final prototype!
• Treat the fully extended prototype as the baseline specification. Oce we have a baseline prototype, we can have valuable benefits, these activities often end up on the critical path, so it is pretty important to identify them from the beginning.
• Write a detailed end-user documentation based on a prototype. On average, Moana would leave the story-telling until the end of her adventure, but it is important to have it from day one.
• Create a separate, non-user interface requirements document. Wow, those are fancy words to say "create a manual". Maybe we as millenials don't appreciate manuals but they a re pretty useful when you get presented with a scenario that the user is not familiar with,

There  you go adventurer! Now you are ready to go and find Te Fiti!

Surviving at the Software Industry (7) - Creating an Indominus Rex.

Do you remember when Claire wanted to create the biggest dinosaur so they could get more people going to the park in Jurassic World?

When you have a goal to achieve it is important to have a vision, a mayor achievement to reach and to feel accomplished when you get it. The vision doesn't have to be something as big as the dinosaur, but it has to help your team to feel inspired so they keep working on your project. You as a PM have to know what you should be leving out of a vision. It is as important to know what we want to do as to know what we don't; this is essential for maintaining the project risk level on a manageable level. When you have a formalized vision, now you have to make all your team to commit to it.

In the movie, we see that the main problem of the park is that they are not getting as many visitors as they once had. The money is the principal issue there. The Jurassic World has to get a Sponsorship from a weapon company so they can create the new dinosaur. On a real project it is actually the same thing. We need to get an executive sponsor, a person who is resposible to say if the application is ready. What is right and what is not.

After getting a sponsor, we have to communicate our project scope targets that you probably won't fulfill. As on the movie, you will experience complications on the making that will delay your delivery. When they try to accelerate the first show of the Indominus Rex is when everything starts to go crazy. Instead of giving an fixed time for every stage of the project give some time scopes so you have larger margins to deliver it on time.

It is important to share to the team in what stage of the project is everything at every moment. The Indominus Rex was being developped as a secret and no one knew how to react when it escaped. The plans have to be revealed and reviewed. The administration of the project and the developpers have to be on the same team, or it will be a mess.

So, here's the biggest problem of the mega-dinosaur on Jurassic World. They didn't consider the amount of risk of the project and they developped a destructive, uncontrollable weapon that killed hundreds of people and dinosaurs. We should devote a part of the budget to risk to serve as a cushion for risk management. The Top 10 Risks List is a tool in which we mention all the top risks at every phase of the project.

As a project manager, you have to create some stategies so you don't die on the process. You hace to be able to be accountable for the actions of your team and to administrate them right. The staff should be a manageable number where all have some work to do and feel like a part of the team. The dynamic of the team has to be appropiate for everyone. If you find people on your team that is being malicious, then you don't have to tolerate it and act as soon as possible, or they could make that your dinosaur become a weapon instead of an attraction without you knowing what happéned.

It is good to document your time use. It can be valuable information on the development of future projects, It also enables you to compare estimated data and actual time on every phase. We do not have any proof of this happening on the film.

When you have all these information in hand, then you can do a software development plan. they are not as detailed as the ones created before, but should be done anyway. If they had a good team on Jurassic World they wouldn't have had that tragedy and the Jurassic World would still be open.

I'm pretty sure this is the longer post I've written for this course, so yeah, here's a gif with the MVPs of the movie, the Velociraptors.