[MUSIC] It may seem strange at first, but putting in too much effort into a project can be a problem. However, what about the case of putting too little effort into the project. I'm not talking about hiring lazy developers and not meeting deadlines because of it. That's another problem entirely. No, I'm talking about management practices that make it difficult for developers to do development work, because they're so focused on doing other things. There's a reason why agile software development focuses on working software over comprehensive documentation. That reason is that comprehensive documentation takes time, valuable developer time. I'm not saying that documentation shouldn't be created at all, that brings about its own problems. Focusing on comprehensive documentation is an example of an anti-pattern, called Viewgraph Engineering. Like gold plating, this is a result of unfocused work, or not working on important, high-value things. Viewgraph engineering is when developers kill their productivity by spending more time building presentations, reports, and documentation, instead of developing code. This often happens at organizations with vertical management structure, organizations where in order to prove a concept, a developer must fully analyze its potential before going forward. It's a lot like analysis paralysis but at an organizational level. The best solution is to remove barriers blocking your developers from developing the product. Often, the time spent creating all the necessary reports and presentations would be enough to create a basic product prototype. The prototype is often more informative than any report can be and comes with a bonus of having working software off of which successive products can be built. If it's decided that the product wouldn't be worth your developer's time then the prototype serves as a lesson learned. A lesson that can be carried on towards future projects. Reyhan is a software product manager who has her developers present ideas to her weekly meetings using a slideshow format. She does this so that everyone's ideas can be expressed accurately and clearly. What is the problem with Reyhan's expectations here? A. The developers time, would be better spent developing code. B. Nothing, this is a good communication practice. C. Software developers are bad at making slideshows. Or D. Slideshows do not give the full scope of a problem. The answer is A. Software developers have only a finite amount of time to work on projects. If they spend their time building presentations, then they'll have less time to create the actual product. Imagine that your development team is focused on coding and managed to complete all their work. Is that enough to say that the project was successful? Well, not exactly. What about the all too common situation where developers are forced to work overtime towards the end of the project to meet deadlines. This happens all the time. This anti-pattern is referred to as a Fire Drill. A Fire Drill is what happened when developers do too little work throughout the majority of the project and then all of a sudden need to make a big push toward the end. This can be a result of lackadaisical management or the impact of a developers themselves wasting time. It can also occur when expectations are not properly set with the client. The Fire Drill is dangerous, because it often leads to sacrificing code quality in favor of getting the product out the door quickly. What could have been a wonderful product ends up being mediocre, since there wasn't enough time to build the product properly. Fire drills often lead to another anti-pattern, called Heroics. This is a tongue in cheek way of describing what happens when your project relies on one developer's nearly superhuman technical skills to get the project done. This is risky. People become reliant on that person to get the work done, even outside of the big push at the end. The best way to avoid this, is to establish expectations with your client early in your project and follow an agile software development practice. You could implement time boxing and other planning techniques that give your developers the structure they need to get things done on time. It also helps when managers and their development teams are equally motivated to complete the project. If everyone works at a steady pace, there's no need for fire drills or heroics. Which of the following describes heroics as it happens in software development? The software development team: A. Is award winning,. B. Often relies on one person to solve their problems. C. Contains someone who has been knighted. or D. Regularly rewards good behavior? The answer is B, heroics in software development is not a good thing. It's usually a sign that your projects could stand some improvement in processes or training. What happens when the development team and management are at odds? What about when management struggles to get the development team to believe in the work they're doing? This is called a Death March. Everyone on the development team knows that the project is destined for failure, but everyone continues to build a project anyway, out of obligation. Imagine the terrible consequences of this. Some causes for how this might arise, are management forcing the project on a development team for financial reasons. Or management might be stubborn and in denial of the inevitable failure. Whatever the cause, if the very people who build the product don't believe in it, you can pretty much assume that the product isn't going to be the best it can be. Developer morale in Death Marches is low and the product quality suffers for it.
