Software development project: Getting things right at the beginning
Why the first stages of a software development project are the most important when you’re starting a new software development project? It’s so important to get the initial stages right back in the early days. We used to talk about the waterfall and defining the end result before you actually start a project, now this is changed into a situation where we’re doing iterative development: under the banner of agile, where we deliver value each sprint without setting a realistic goal, and without setting a target or a roadmap. At the beginning of a software development project, you’re setting yourself up for failure. These things can damage the project or the product, long time because there’s no defined end goal in mind.
The other reason why it’s so important to define things upfront is that it allows you to try things out along the way. They may or may not work. If they work, that’s great. If they don’t work, you already know that’s not good. For this, it’s really important to make sure that you set some time apart. At the beginning of the project to prototype, new ideas can come up, or you may need to do a proof of a concept, or a particular method of doing something, so you make sure that it is going to work.
“It is more important for code to be changeable than that it works. Code that does not work, but that is easy to change, can be made to work with minimum effort. Code that works but that is hard to change will soon not work and be hard to get working again.”by Uncle Bob Martin.
It’s extremely important to consider that people’s and company’s priorities can be changed throughout the project. You’ll get halfway through a project or you might be five sprints in it, and you might be releasing new functionality every week. However, somewhere along the line, someone says: “Oh, crap, I’m going to change this.” The way that we as developers deal with that is sometimes: “We can’t change that. That’s impossible.” Or we say: “God, you’re always changing your mind!” and we really get frustrated. It shouldn’t be that, we should be going great. Okay, if you’ve realized that that didn’t work, how can we change it? Is this possible? And we shouldn’t be fearful of the fact that the code is so crappy that we can’t change it.
Microsoft pinball was is an example of an unchangeable code. Raymond Chen was tasked with porting millions of lines of code over from Windows XP 32-bit so Microsoft could ship Windows XP 64-bit. That code included Pinball, but it had a collision bug that saw the ball drop through the launcher and off the table, rendering the game unplayable. It all comes down to source code that was a difficult read and devoid of any comments. With no help being offered from comments or documentation, they had to give up and then Pinball disappeared from the next version of Windows.
Expectation setting is a really important thing to get right at the beginning of the project. Who’s doing what and who’s responsible for it. What should the developers expect from people within the business, what do they expect from the developers, and what they expect them to provide, and when. What does the business expected the development team? What do they expect from the testers? What sort of turnaround we talking about and how much do you think we can fit into a sprint or into a release? Realistically what training is involved? And, you know, if the development team releases something there’s probably going to be another three or four weeks of training, or maybe there’s not. But those sorts of expectations should be set upfront.
Definition of wording
Definition of wording and things, a common language that people can use is really important, especially when we’re talking about requirements gathering. If you’ve got a wonderful department to course the field, a field in a database x, and then you’ve got another department that calls it, giving that shared terminology is really important because it ensures that they’re all talking the same language and that they’re all talking about the same thing. If it happens that the same field has different names and different departments, that should be noted and should know about that. So when someone says: “Our surname”, you mean the last name column or things like that. Additionally, getting the terminology right on how you’re calling things, how you’re calling an iteration or sprint is also important, so people don’t get confused budgets. Obviously, budgets are important to get right. So you know what to expect but that’s I guess that comes under expectations.