Mistakes what we are doing frequently in Software Development

1. Not understanding the user’s needs. Lack of user input, or not even asking. 2. Underestimating the size of the project. 3. Rushing through the planning stage, or avoiding the planning all together. Code first, plan later! BAD! 4. Not testing early enough, often, or at all! Make it a habit! 5. Choosing the “Cool” methodology at the time, vs. one that has worked in the past. Which leads into my next point… 6. Not using a methodology. 7. Letting a software developer run the software development project. 8. Bored, unmotivated team! You have to motivate your developers! If you can’t motivate, don’t bother trying to lead. Your team will fall asleep, literally. 9. Planning on catching up later. You won’t… don’t even think it! 10. Non Source Control! Ouch.. not good people… and no, just installing a software package is not it… 11. Deciding to switch your development tools when you’re already into the project. 12. Allowing feature creep. Just say NO! Everyone will be happier in the end. 13. Omitting necessary tasks to shorten the project plan. Really, what’s the point of doing this? 14. Insufficient management controls in the development project. 15. Lack of high level business sponsorship. 16. Adding people at the end of the project to “speed things up”. You will only slow things down… 17. No unit testing. Heck if you can do it, use Visual Studio Team Foundation Server and set up some automated testing nightly. 18. Stressed out software developers. If you have managed to perform even one or two of these software development mistakes, you will have a stressed out bunch of programmers to deal with! 19. Lack of error handling. 20. “Off by one” errors. These happen a lot during the software development process.. *sigh*. 21. Typos… Just use option strict and explicit please.. during one software development project, which I was on as a consultant, they were getting ridiculous amounts of errors everywhere… turned out the developer couldn’t spell and would declare variables with incorrect spelling.. no big deal, until you use the correct spelling when you’re assigning a value to it… and you had option explicit off. Ouch to them… 22. No understand the deployment or hardware the software is to be installed on. Ohhhh it’s for a Macintosh… lol. Well hopefully not that bad, but you get the point. 23. No naming style or code conventions. Honestly it doesn’t matter what you use… as long as you are consistent with the rest of the team, and hopefully at least yourself. 24. Using global variables everywhere. These are NOT your friend and hog memory like nothing you have ever seen before! 25. Not asking for help at all during the software development process. If you’re stuck, don’t fight with it for hours on end! Ask for help! 26. Not commenting your code. 27. Hogging all information to yourself. You think you’re more valuable this way? You’re actually not and there is a plan brewing to get you kicked off the development project, and possibly out of the company. You might want to brush up your sign “Will code for pizza!”. 28. Performing database operations at the application layer instead of the database layer. Not only is this putting the processing juice on your application instead of your server, but you have put your database at risk of data integrity issues, and getting bad data! Some of my hipster cool friends are always saying “It’s alllll good”, well, if your database can be caught saying this… and If everything looks good to your database, then you should be worried. It is NOT all good! 29. Not validating your data! Yikes… Yes.. let’s just assume all the data is perfect! NOT! 30. No load testing. What.. This is supposed to run on 1,000 user’s machines through Citrix? Interesting… Shouldn’t be an issue! lol… NOT. Credit goes to Original Author : http://www.realsoftwaredevelopment.com/

Software Developer - Must Know

1. Time spent writing great code It’s not about the quantity it’s the quality! However a twist to this is: It is about the quantity, and the quality. Far too many times you will get one of two scenarios. In scenario A, you have a developer that pumps out code like mad, things seem to be working… then bugs start happening, you don’t know why, seems to take forever to fix! Or they fix 10 and cause 5 more! But you get a lot of code… In scenario B, you have a developer that seems so smart! You interview him and he knows everything about everything, can speak the theory up and down! Yet for some reason, you have assigned him three features, and three weeks later, he is still working on something that should have been done in 3 days! You are so confused! He is so smart! He knows everything about generics, multi-threading, and can explain pointers to your grandmother and make her excited to want to code! Why is nothing getting done?! In your dream scenario, you get great code! Great code is done by a great developer that is super smart, knows what quality code is, and writes code like Tony Hawk rides his skateboard. It looks so natural! He or she is almost entertaining to watch! They also get it done at blinding speeds! They know how long each problem should take, and do not get caught up in finding the world’s best solution, that has multiple threads and layers, to write a game of pong. Bugs are nonexistent because they write unit tests for themselves, and just plain can code in their sleep! These guys are worth their weight in GOLD! 2. Interpretation of the problem So there is a problem out there, with millions of ways to solve it. Some people are just natural quick thinkers and can come up with multiple solutions instantly. However, what a great developer would do is totally define the problem before doing anything! A great developer will create a document or whiteboard the problem out. They will email their managers and say things like “Can we meet so I can explain to you how I understand the problem?” Next they will start giving you various solutions, etc. See, a great developer knows that the way they see the problem and interpret the problem, is probably not the way that the problem creator intended it to be understood. This is a key point, commit this to memory! A great developer will want to understand it fully, before attempting to approach a solution. Do you understand the problem 100%, no? 99%? Go ask more questions and be sure you are 100% clear! 3. How the problem is approached So once you have clearly defined the problem, you start coding right? Wrong! A great developer will look at the layout, and start thinking of various options, and based on the problem, will start thinking about the best approach to solve the problem. I view this like a game of chess. You can know how all the pieces move, know all the rules of the game, but do you just start moving? No! You analyze the board, come up with a game plan, look at your opponent, and look at what he or she usually do. It’s the same case when you approach a problem. Look at the problem, figure out what the outcome needs to be, what kind of time you have, the quality being expected, the tools you have to work with, etc. Then, start solving the problem. 4. Confidence in code As a manager, how confident can you be in their code. Some developers you can say “I need this completed by Friday” come Friday, you get an email saying “I have checked the code into the branch, it is ready for testing” and you just know that there will be very little, if any, bugs found by the quality assurance team. On the flip side, there are some developers that will email you instead and say “I am still not done, and it will be done on Monday morning first thing.” And you are nearly 95% sure that it will be there, however it will be ridden with bugs, and basically unusable for days, if not weeks, until bugs are completely ironed out of the code. Bottom line: The higher the confidence you can have in a developer, the closer they get to being great developers! Imagine being your manager, and the weight you lift off their shoulders if he doesn’t have to worry about your code! 5. Confidence in the solution It’s one thing to be confident in the code. If you have a great developer on your hands, you are confident in the solution. These great developers will be great architects. They are able to dissect the whole problem, and figure out how the problem needs to be solved. See it’s not just about coding with great code, it’s also largely about how you architect the solution! This is a key point, and really what separates the good, from the great in the software world. 6. Meets user requirements At the end of the day, you can have the best code, and the best solution possible, with all the best architecture, but does it meet the user’s requirement? It’s possible not! And you have completely failed. Now there are various degrees of missing the mark, but a great developer will hit the bull’s-eye consistently! They find out exactly what the user wants, come up with a great approach, show the user what they will get every step of the way with weekly builds that have no bugs, and continue to build upon the last version. Requirements are bang on, and the users do the jig! 7. Staying up to date Great developers are constantly updating their skills independently and proactively! They thirst for new knowledge and perfection like a cat with milk. They don’t wait for their managers to come to them and set goals, ask them to take courses, or are given books to get up to speed on. They go and get these things on their own! They find the conferences they want to go to, and send emails like “I would really love to go to Tech-Ed This Year! I will learn , and I will be able to contribute to . I foresee this saving us . If it’s at all possible, can the company help me pay for this trip?” If someone sent me this, I would not only help pay, I would pay the entire trip! Great developers are always attending all the user groups, like a .net user group for example, or a Java user group. They go to the “free local” meetings, and do whatever it takes to feed their brains! Do you read all the latest blogs and magazines? List your top 5 favorite development blogs right now! Can you do it? You should be able to drop them like you can do the actions to the YMCA! Stay up to date, it will stretch your mind! You will have the next big idea! You will be rewarded! 8. Contributes to team You can be one of the best, if not the best coder, architect, most brilliant guy on the team, but as far as I am concerned, if you are not able to share and contribute to your team, you are losing about half your value, if not more! A great developer makes others great around them! See, a good developer keeps getting better and better, but doesn’t share the knowledge they obtain, or how they obtain it. They learn new things, find out about new technologies, but don’t let anyone know about them! A good developer finishes their projects on time, but when push comes to shove, is not there for the rest of the team. A great developer is in touch with all the projects that are going on within the team, and is ready to lend a helping hand when needed! They will say things like “I noticed team A is working on , and I think I can help out, do you mind?” 9. Makes great meeting minutes This is incredibly important! There is nothing worse than calling a meeting, taking the time to explain new concepts, new ideas, brainstorm, come up with great designs, and not have anyone taking meeting minutes! Even if you have a designated meeting taker, I want to see everyone showing up with a pen, and paper (developer notebook is preferred). A great developer takes great notes! They write out all meeting minutes, and at the end of the meetings can be heard saying “So just to confirm, my action items are: . Did I get everything?” Next, a great developer will send their meeting minutes to the manger, listing the date of the meeting, the topic, and attendees. Following this, you will have the action items at the top, with who is the champion of the item. Below that, you have the detailed meeting minutes. A good developer, takes no meeting minutes, says yes every time you add something to his list… and hopes that his memory will serve him well. He then later emails you to check out his changes, and you cringe as you see he forgot a few things, but got 90% if it correct. This is a HUGE WASTE of time! For no reason at all! Take Great Meeting Minutes! 10. Teachable and takes criticism well If you have read this far, then hopefully you are taking all this in and will be trying to implement some of my suggestions in your day to day development efforts. See, another key area is the developers’ ability to learn from others, and take criticism well! By making yourself a teachable person, you turn into a sponge, and absorb enormous amounts of knowledge faster! Your seniors are there for a reason! Sure, they might be rusty at day to day coding, but they have gone through the trenches, and been through hundreds of battles, and have the wounds and scares! They have the “Blink” instinct to make great decisions, and make you great! They are in the position they are in because they LOVE to see you succeed, and want to make you grow! Of course, this is the ideal work environment, but that’s where you want to be anyway if you are a great developer! I absolutely guarantee you, and promise you, that the better you can improve this skill, make yourself extremely teachable, make notes on suggestions and criticism, and make a point of improving them, the better chance you have at becoming greater than you have ever imagined possible! If you on the other hand, choose to think of yourself as “elite”, and have nothing more to learn, you will always be stuck where you are. If you are not growing, you are not even staying at status quo, you are dying! Grow! 11. Always available when needed This is a give and take. If you are working for a great company, they will be flexible with you. They should never question doctor’s appointments that you couldn’t schedule after work, start times, end times, or lunch breaks. They should encourage you to go to the gym at lunch, pay for lunches when you go out with the team, etc. They should give you a few days off after some crunch time work. This list goes on and on. However, with all those perks, comes responsibility, no question! If it’s crunch time, a great developer will suggest to you that he will come in on the weekend if needed. They will stay as late as possible and as late as is needed to ensure the job gets done! See, great developers take responsibility for their creations! Now, this is not a necessity of course, but it is the mark of a great developer. Some people just want the 8-4:30, and will be good developers, but they will never be great. Great developers are team players to the end, and view their work like art, and view their team, like a family. 12. Dress’s professionally every day You never know when a client will come by on a tour. You never know when you will be called into a meeting, not everything is planned. And when that time comes, you have to be ready to dance! A good developer wears normal clothes Monday to Friday, even stretches it with black jeans, and runners that look like dress shoes. On casual Fridays, they wear shorts, runners, and a T-shirt. When the tour comes by on Friday with a new huge account, you can’t call on him to join you for lunch because he is not dressed appropriately. A great developer dresses in great business clothes Monday to Friday. They dress for success! See, by looking the part, you become the part! Of course, if you have no skills, you will not be promoted to a manager or team leader just because you dress sharp. But if you have great skills, and dress in a suit and tie, you have just catapulted yourself up in rank, no question. The 400 dollars you will spend on a decent suit and tie will pay you back within the year. I promise you! 13. Communication Ability This is another critical category! There are so many good developers out there, but there are not a lot of great developers. Why? Because a lot of the good developers, are terrible communicators. There are many levels of communication, ranging from email, to small SCRUM meetings, all the way up to large executive meetings and your ability to contribute at the executive level. Then you get to “The Show” where you are presenting for hundreds of people, showing off software. While you don’t need to get to the final stages, you need to be able to at least communicate your ideas clearly and effectively in meetings. The better your communication, the farther you will go. Bottom line: If you want to be an executive, you have to be a 9 or 10 at communication. Even when you take meeting minutes, or send out status reports, you need to communicate extremely well! Don’t just say “I fixed bug 1371″ on your daily report! Show off; explain how hard it was to solve the problem, how long, or how quick you solved it! Explain the technology you used! And explain how you will ensure the problem doesn’t happen again. Your status reports should not be a bad thing you don’t like to do! They should be an exciting part of your week where you get to show off to your manager! 14. Goal Setting Skill Good developers can get things done, and go throughout their day to day by doing what you tell them to do. They don’t really think far ahead and think of what they want to be doing in a year, five years, or even 10 years. Some good developers know what they want… but have no real plan to get there! A great developer has the goals for the year, the next five years, and knows roughly where he will be in 10 years. Great developers also take it to the next level by not only thinking about their goals, but also visualize it! They can see exactly what they will be doing in five years, to the level of where they will be doing it. Even more, a great developer will create a detailed plan for his next year, complete with courses he will take, projects he will complete, and relationships he will build. 15. Organizational Skill The final key component that really brings everything together is organization. You may be the best developer in the world, but if you are not organized, you will fall apart and become bogged down! Eventually you will be overwhelmed and start losing your edge. Great developers keep an extremely clean desk, they keep all their notebooks, and write very clearly. They print out their daily outlook calendar of meetings and tasks. They have an inbox process to deal with emails, meetings, and new assignments. They keep file folders and can instantly pull up projects, meeting minutes, and other details when asked to produce them. Bonus Tip: Passion! One of my team members read my post and reminded me of something that every single person on my team has in buckets! Passion! Without passion in what you do day to day, you will not be a great developer, or great at anything for that matter. Lack of passion is the number one reason so many developers never become great! It is also the number one reason people do not succeed! A passionate developer will outperform even the best technical developers if they are not passionate about their job, their role, and their project. Think about it, if you have read this far, are you going to make an effort to make all the changes I listed? They seem simple, but without the passion to do these things, are you really going to commit today and be successful? So there you have it! These are some of the key principles I am using in rating my development team during the review process. Mind you, I provide my team members with the best environment I possibly can, and in return I want great developers! And they want to all be great developers! You can use these rules to rate your developers, or if you are a developer yourself, please use this list to make changes if needed, and catapult your career past your peers! Credit goes to original author : http://www.realsoftwaredevelopment.com/