There's a glaring problem I've noticed in my paltry 8 years of developing software and it's that on most projects there is an expectation of a perfect buttoned up system with zero defects on the first day of rollout. I've also noticed that while great intentions are had at the beginning this futile attempt your project ultimately fails miserably from a budget and schedule perspective time and time again. This is what leads me to believe that "Perfection in software development is unattainable"
The sooner you understand that your work is never going to be perfect the better developer you will become. Getting to a point where you can look at your work and say that it's done should not and will not ever happen. Never be afraid to push out work that isn't perfect or done in everyone's eyes. Something imperfect that is used is extremely more valuable than a pile of code that no one has ever interacted with. Exceptions to these rules are your true mission-critical software systems. When I say mission-critical I don't mean the new CRM or point of sale system your CEO keeps talking about as mission-critical. I am talking about software written by the likes of nasa or airlines that have significant safety requirements that if not met would result in death. Your customers and clients deserve to get their hands on working software earlier and your ego should not prevent you from providing them this level of service.
The reality of all this is that we consistently lie to ourselves and our customers. Ken Schwaber and friends have attempted to bring these issues to surface with the Scrum methodology but the problem with adoption is people not the process. Lying to your customer has sadly become an accepted business practice. Honesty can't be an option because "The customer is always right." Companies also want to get business in the door and grow business which is a noble goal. These accepted business practices work all well and great if you only want to work with a customer once or have high turnover due to burnt out developers. I can't help but think about this picture whenever someone approaches me with a hard deadline that you must agree to 4 months out.
The reason I feel this way is that we can and will never be able to deliver on what we promise 4 months out. We tell ourselves that it is unacceptable to provide or present our customers with anything less than excellence and high quality and never define what that means on each project. The result ends up being a strained relations relationship after missed deadlines and schedules that are promised by people who don't execute the project or in Scrum terms you're chickens are dictating when work should be done rather than the pigs. Think about how many times you've been talking about a project midway with the customer and you have a ton of issues internally but the conversation always ends up with, "Yup everthing's on schedule talk to you next month," Then you deliver the product and the customer has questions, changes, comments that result in more work.
This principle of gedd will naturally result in accepting agile as a practice or methodology and using this principle while you develop will help you achieve progress during your sprints. This doesn't mean you should release or develop crap the same way agile doesn't mean you never document or design anything. You need to be disciplined and understand your craft but you also need to throw out your heavyweight practices that don't work, always learn from what you did previously, and don't be scared to fail. Get over yourself because you're not perfect and never will be.
