Engineer - Mastering the Art of Software
•Descargar como PPTX, PDF•
4 recomendaciones•952 vistas
With the evolution of software, starts an evolution of the software developer and how things are approached. A different and more responsible mindset is now required and with that comes the use of the Engineering Cycle that will provide not only the basic skill set but also the core base for a Software Engineer to handle any type of project.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Engineer - Mastering the Art of Software
Similar a Engineer - Mastering the Art of Software (20)
Último
Último (20)
Engineer - Mastering the Art of Software
- 1. Engineering Mastering the art of Software
- 2. A challenge
- 4. Research
- 5. Spoon Manufacturing As a business owner I want to expand my business by manufacturing spoons. These should be made of plastic, lightweight and will be distributed in small boxes of 25, 50 and 100 units.
- 6. Ask the right questions ● Who is your target audience ● What are the project goals ● How the project will be distributed ● What are the project requirements ● What are the project restrictions ● etc
- 7. If doesnt work on paper ...
- 8. Development tools Let’s talk about hammers:
- 9. Digital Sign If you had to build a digital sign by hooking up a computer and a tv, what languages, frameworks would you use to build it?
- 10. Development tools Step back and put it on paper. Can it be diagramed in a flow chart Can it be broken down into more stories Pros and cons of the selected language Pros and cons of the selected database What is the learning curve, if any, for development Are there any risks with the chosen path for development etc
- 11. MVP Minimal Viable Product ● Clear view ● Requirements ● Restrictions ● Goals ● Next steps
- 12. Develop
- 13. It is not only about code anymore ● Standards ● Reviews ● Instructing other Engineers ● Tests
- 14. Management Skills Not people management, Risk management! Everyone has probably faced some sort of scope creep Need to understand and manage the risk of a change set “Doing it live” is the same as risk management not being important.
- 15. [Risk] Management Skills Consider the scenario: The application is completed, fully tested and in the a week before the release day, business decides to change the default payment authorizer to one that the application doesn’t support yet. How do you manage this scenario and what would be your recommendations as an engineer?
- 16. Visibility & Feedback ● Collaboration ● Tests
- 17. Back to MVP
- 18. Adjust
- 19. Cabin in the Woods Consider the scenario: You are walking lost on the florest, it is cold, foggy, dark and with some bit of luck you find a cabin in the woods. You manage to get inside and, once inside, you see: A gas stove A fireplace with some wood on it A kerosene lamp What do you light up first ?
- 20. Types ● Improvement ● Fix ● Hotfix
- 21. Troubleshooting It is more important that usually is given credit for Requires a detailed and yet abroad vision Good troubleshooting skills can help during development phase
- 22. Hotfix Extreme case scenario Disruptive Requires prior-planning and quick response
- 23. Hotfix Planning Short version: Responsible people for roles: Engineer QA Release manager Dev-Ops Post-mortem
- 24. Improvements ● Usually mistaken by easy ● Requires the whole engineering cycle ● Requires risk assessment
- 25. Engineer
- 26. Mindset It is not about only code anymore... It is a dynamic exchange of thoughts that fiddles between an architect and a experienced software developer.
- 27. Mindset Anyone can: Research Code Adjust ... but in order to work with all 3 you must have a different mindset of a programmer / developer.
- 28. Back of to the challenge
- 29. If you are wondering ... Thanks @LauraG309
- 30. “Sometimes a simple solution is far far more powerful than a conventional off the shelf way.” Manu Prakash
- 31. Now I’m ready for questions and answers ... I mean I guess
- 32. About me Cristiano Diniz da Silva Soft. Engineer, techie, geek, nerd, enthusiast photographer... proud father of two girls and happily ever married. Working with PHP since it’s 3.2 version @mcloide https://github.com/mcloide mcloide.com Engineering & Photography https://joind.in/talk/47c87
Notas del editor
- Today I will tell you a quick story about engineering; about how software engineering to be more precise will completely transform the way you work, the way you think and the perception of your peers to you. It all started in a galaxy far far away when a jedi ... wait .. sorry .. wrong story. Anyways ... Engineering has many forms and software is just one form of it. My name is Cristiano Silva and I’m here to not only tell you this story but also to guide you through all of this. In fact how about a little challenge.
- The goal of this is provide a challenge, how can we power this tricycle with these 2 power drills. Obviously it needs to be capable of being driven by one of us and to gain speed. Don’t answer now, this was just to get you guys thinking. In our line of work what we do the most is to find solutions for problems that are usually presented by business and takes in a form of software but we are smart people so we can solve any kind of problem right ? How about solving this one. Here we got a tricycle and battery operated drills. The goal here is to use the drills as an accelerator to the tricycle. If you are wondering why ? Simple why not ? Seems fun, dangerous, require some skills to engineer something like this, and again, we are all smart people. If we are capable of developing software we are certainly capable of solving this right ? Now that I got your curiosity, let’s move on. I will get back to this challenge later on, for now, please just think about it a little bit.
- Just like SDLC (software development life cycle), engineering a software has a cycle of it’s own and it consists basically of: Analysis, development and troubleshooting. Where one of this phases usually takes longer than the other. If there is no time being properly spent in any of these phases, it will consequently affect the following phase. If you don’t take proper time during analysis and development, you will surely take time with troubleshooting. These 3 cycles can be also expressed as: Analysis, Development and Troubleshooting / Bug Fixing.
- I believe this shows how most of the user stories that you will be getting out there truly reflect. All that states is a “want” or intention. It doesn’t really tell all the information that you will need to prepare a project that will in fact generate the spoons and set them in the boxes as specified. The interesting thing about this little project is the questions that you should make. A spoon is used for eating. Usually to eat both cold and hot foods. Usually to eat both solid and liquid foods, even knowing that liquids might be tricky. These are in fact the most common uses of a spoon. So if a client calls in saying that the spoon does works well for him, then you got understand why. Obviously if someone is using a plastic spoon to dig up a tunnel to escape from prison, that is not the goal of the use of the spoon.
- The point is that by doing analysis and research you should be able to figure out what is the best path of development for what is being asked. By doing analysis important development paths such as what languages to use and how to implement will be answered. Along with that other aspects such as missing information from the user story will also be found and this is what will avoid issues after development. Who here has never found a missing requirement after it was developed ? It is understandable that most of us will believe that these should be answered by a business analyst, but in fact, these should be asked by an engineer to begin with. It is from the most interest of the engineer to find out how to properly approach a given project. Knowing all possible aspects of the project will help identifying possible pitfalls during development time. A great example of this is backlog-grooming where the team or the responsible parties go over the features to be developed and pieces of feature are defined little by little till there is a solid definition and understanding of what needs to be done.
- This is probably one of the most quoted quotes I have heard during my career as an engineer. All that it says is that usually if you can’t visualize it on a piece of paper you won't be able to visualize it during development phase. If you can see it you can build it right? More importantly if you can see it, you will be able to define what tools you will need to use. What path you will need to take to correctly develop that project.
- Although these are all hammers in some form, or, would belong into a hammer category, each of of them have a unique use. The rubber hammer (mallet) is generally used to place tiles, while the common hammer is used place nails. Thor hammer, well you shouldn’t .. just shouldn’t. Although the tools are pretty much the same they don't necessary perform the same operation and that specific is what makes the tool selection important and how relevant will be to build your own tool versus getting one of the shelf.
- This was in fact a little project that I have been playing for the past month. I have used a raspberry pi and a small tv and the goal was to rotate ads, images, something that I could control, on the tv without showing anything from the desktop from the raspberry pi at all. Considering what needed to be done, the first thing to do was to research. Find out if with HTML I could rotate some images in fullscreen. The answer is yes, bootstrap carousel can do this to for you. The 2nd step is to load a browser in fullscreen. This took a lot longer as research, but there are browsers on Raspbian that can open a page in fullscreen and both of them can be executed through command line. Now that I knew what to do, all that was necessary was to properly select my tools, that, in this case could been anything from HTML with JQuery and Bootstrap to a full blown Symfony application. Truth is that opting for simplicity is usually the best path and simple can be really sophisticated.
- Although analysis is considered to be a necessity in most of the software development houses, not all and not everyone does it, but it can save a really good amount of time during development and adjustment phases.
- By the end of research phase you should be able to have a really good definition of what would be a minimal viable product. MVP is nothing more as the definition of what is the minimal necessary for the project to deployed to production. A great example of this is a subway system. What is the MVP of a subway system: A station, a line and a train. By the end of research you should have a clear view of what needs to be delivered, how long it will take to deliver, what is necessary to deliver it and what is next following the delivery.
- Any developer can place code and make it work, but fact is, now coding is also about how other developers / engineers will perceive your work. You gotta make it work, make it fast and then make it perfect. When you submit your code to review it got bet understandable and efficient, gotta pass the build and gotta work. The decisions that you take during development time will directly reflect on the time that will be spent for adjustments or how we call it, bug fixing. Today there are tools to help us with that, for example, PSR’s , GitHub and GitLab does have a form of code review, there are unit tests and if all is properly done you won't have any issues on instructing other engineers about your code or another path their code should be taking.
- The idea is that this part of the daily life of a software engineer. When you are developing code you must be able to determine how risky or how impactful is a given code change / introduction. Can that feature be safely introduced without impacting other parts of the application or without breaking backwards compatibility ? Can that code be removed safely ? A nice example is the case where the maintainer of the left-pad, a npm package, removed it and millions of projects that had that dependency were broken because of the missing package. It is true that the risk assestment should be done in analysis as well, but most of the times it appears during the development phase.
- Understanding how risk the change will be for the given application will provide a more detailed and more focused answer to business that can help deciding on how to perform the change. Will it be as a follow up improvement. Will the release the held for a long period of time until the request is done and tested? Understanding what is being asked and how impactful it can be will give you better room to negotiate with business and to prepare to develop the request.
- During the ending phase of development you want the most visibility and feedback possible. You will gain visibility by providing unit tests with a reasonable code coverage (and be realistic on this portion here) and you should collaborate as much possible with business and QA to see if goal of the project has been reached. As an engineer your goal here is to reach the 80/20 rule. While you will spend 20% of your time developing a piece of software that works for 80% of your target audience, you will spend 80% of the time developing the software to work for 20% of your target audience. This rule is extremely useful especially when developing because, if you did spend your time wisely during research, you should be able to a software that will work for anything between 80 to 99% of your target audience. Honestly, if you manage to get 85%, that is amazing.
- At this point you will have already researched and developed the project/application. This is usually the point that is decided if the project will be extended to full feature or if it will be placed out in production for an early feedback. In product development there is something called the “bell curve”. If you are developing a brand new product that will be placed on market and all your lifetime investments are on it, then you must understand this curve. It basically says that, once you overcome the Early Adopters gap and gain about 18% of the market share your product will be widely adopted by the majority of the users. Why this matters for you as an engineer? This curve will dictate how much adjustments you will be doing to overcome the 18% threshold. Anything past that is mainly business and new product development.
- The idea is to show how you must see outside of the box to troubleshoot something. It doesn’t mean that something that needs to be fixed is right on your front. Bug / Defect fixes can be simple at times and they can be really silent in a way that the condition that is being informed as a bug, defect is simply a reflection of some other, and possibly, major issue. In the case of the scenario presented by the Cabin in the Woods, the underlying issue was that you needed light to match in order to light up the one of the options presented. A follow up question from this would be once the match is lit, what should be the first thing to light up. The answer to this will be different from engineer to engineer and it determines how one think and approaches troubleshooting. In the end, after the match is lit, any other thing could be lit with the same end result. I would preferably start with the kerosene lamp because it is most likely to be the one that has both enough kerosene to start a fire and could be shared to the gas stove and fireplace.
- There are 3 distinct types of adjustments and all of these occur after development is done and by different reasons. Improvement, which usually means that something was missing during phase of analysis either by business or by the engineer responsible. Fix which are what we know better as bugs, defects and logic issues. Necessary code changes that were not caught during development time. And there is hotfix, my favorite. This usually happens when the application is sent to production without either proper test or proper risk analysis. During this phase having good troubleshooting skills helps with the last 2 of these types that are coincidently the more common ones.
- As engineers fixing bugs / defects is just part of our daily routine but not spending a lot of time by having a clear understanding of what the issue really is at the first place will avoid that the fix implemented doesn’t generate other issues.
- Hotfix, production fix, critical fix or any type of fix that has to be quickly deployed to production because it does break the application or causes damage to business and users it is something that has to be dealt carefully but yet quickly. Critical fixes are disruptive. When dealing with a fix of this type you are in fact stopping whatever you are doing and working on this. They are also costly and, like in the example of this slide, it costed Amazon.com a good $4.8M usd. If you consider that maybe it took 10 minutes to fix the issue, another 15 minutes to QA it (assuming that most was automated), 10 minutes to get everyone that is required for a deployment / informed to deploy and another 5 minutes to deploy the code, there you go, you got a 40 minutes nightmare in large scale. I think is fair that a critical fix has to be planned and that is exactly the reason for it.
- This should be a list that should be kept in all times with names and phone numbers in case of a hotfix to happen. There is in fact a talk that explains this very well (try to find it out) but this is the very short version of it. Know who will be handling the release as keeping people informed about the status of the issue and that will manage the process of release the fix to production; The engineer that will fix the issue or will point out who is more capable of fixing that issue; The QA engineer that will test the issue or will point out who should test what it was fixed; Dev-Ops to actually deploy the fix to production. Unfortunately hotfixes doesn’t happen in a planned time. They happen and having a good planning helps avoiding them. As an engineer you must know how to quickly troubleshoot the issue and fix it, but more importantly is also part of the role to prepare a hotfix contigency plan if there is nothing done for it. After the hotfix is deployed then a meeting should be done and a path to a definitive fix should be set.
- I wish that every improvement was something as change the font to something else, but most of the times, a improvement happens because there is a need that the application / project has not met. Improvements are not always complicated but it would be naive to say that they are easy. Every improvement will require the engineering cycle (as well the Software Development Life Cycle). It will require some risk assessment because now it is not simply adding to the project it can also be adjusting a feature that is just not right. There is not a lot that can be said by improvements but the idea is the same, once the application / project is deployed it will require adjustments and if all was done properly then you should be doing a lot more of these than fixing bugs / defects.
- Let’s talk a bit about what will your role going forward and hopefully you won't have to go through the same issues as this engineer has gone through. It is part of the engineer role to be critical especially of his work. Constantly learning and improvements are expected and not only in your favorite language of choice. The reason why an engineer is so critical from his and his peers works is because is a way to not only improve his skills but also of his peers (if they let).
- When you think about impact, risk, what approach to develop that project, what frameworks to use, what programming language to use, etc, you automatically create a different mindset that is not only, let’s sit down, code and make sure that it works. How many here have at least once rewritten a whole project because the initial path taken for it was bad or the whole coding on it was not scalable ? Explain that an architect will probably go further than an engineer and should have a holistic view of the whole project and not only portions of it.
- The idea here is that a Software Engineer will go much further than simply developing a solution. He will check the solution that will be built, he will choose the correct tools for it and will address adjust whenever it is necessary. If you consider that you are building an application on your own for a client and every second that you can spare is a profit done, wouldn’t you be more careful or wanted to do it properly to begin with? That is where the fiddl
- 1st let’s present this in a better way. As a business owner I want to be able to accelerate and drive a given tricycle with the help of one or more battery operated power drills. As a business owner I want to be able to use the battery operated drills to accelerate the tricycle while being able to drive. So the objective here is to be able to use the drills to accelerate the tricycle while a driver is actually driving it. This gives us a good idea of restrictions and variables that can be used to properly develop this project. So, considering this, how would you solve this challenge ? What would be your approach ?
- There is a fun story about this video. While following Adam Savage on Twitter a mother was showing how her 6 year old built a go kart based on inspiration from a talk from Adam Savage which resulted in this. If this 6 year old was creative enough and applied all the engineering concepts necessary to build and pilot this go kart, so can you.
- Try to avoid to overthink things. Most of the solutions that does more than one thing they aren’t really good on doing those things at all. Think about all the utensils that you have on your kitchen, the ones that function the best are the ones that are made to one simple task, like forks for instance. Manu Prakash is an Bioengineering teacher from Stanford that have created the Foldscope ( a paper microscope that can be folded as an origami ) and now he created the Paperfuge that is a centrifuge made out of paper and strings and it is based on a very very old toy. It is not because the solution is simple that it isn’t sophisticated. I hope that this story told will help you to approach software development differently and to start engineering even greater and cooler things. Thank you all.