--Originally published at Debugging My Mind
I’m gonna take a different approach from now on, instead of mentioning things the book is saying by chapter I’m just gonna give out my opinion on the topics it talked about, whether it’s one chapter or the other will be up for guessing but it’s probably more important to identify the topics themselves and what I think of them.
First off we have staged delivery, dividing the project in different stages which all need to be able to be delivered even as a finished product at different intervals instead of having one big thing that is all delivered at once a single time at the end of a project.
I think this kind of project model fixes not only a lot of the developping issues that exist already, but also a lot of the “business” or non developping issues that stakeholders and users have with development itself.
People want results, they don’t want to be told “oh it’s going good” or “oh it’s X % done” and not actually see the fucntionality or what they’re going to receive yet, sadly, since software development is not a tangible thing except for documentation for a long time before you can see the actual program working (at least most of the cases with the usual developping methods) it’s bound to face a lot of credibility issues from the stakeholders and is one of the main problems we see these days.
For me, staged delivery seems to be a really good alternative to face all these problems I mentioned, being able to deliver something tangible in periodic releases involves the end user a lot more, to be able to meet their expectations and for them to see continous results from the development, which might just be worth all that extra effort that can be created from the new overhead required for multiple deliveries and version control.
It definitely doesn’t seem something too simple to transtition on, as pretty as it may sound from explanation alone, but I do think it’s something I want to try for myself and see how it goes, no matter how small the project is. (Having a big list of deliverable milestones and documentations definitely sounds like a big chore and a turn away like the book mentions, but hey, we gotta do it eventually, might as well start early and save ourselves a lot of bigger trouble later).
Next up we got change control, oh boy change control. As a student we often find ourselves stumbling trying to “apply” some of these concepts throughout version control on git, keeping code on a repository that can rollback if needed and help control the whole thing.
I actually think we don’t get enough sort of guidance or classes or teaching that revolves around this sort of stuff, as students we’re usually hesitant to change stuff once we got it going, considering change as a meeting between all members to do something big to the whole project can be difficult after the whole initial idea and planning has gone through, and not only that but even as we try to use git and repositories to keep control, most of the times we’re never fully sure how to utilize its whole potential or what’s the “right” way to approach it, leading into issues and more problems than we want.
I agree it’s important to be willing to consider changes specially propose and look at them in the first phases of development like requirement and planning, where you can do all these changes basically for free unlike in the coding where things get a whole lot more complicated. Clients can be resilient to make big changes way down the road and it’s important to make it real clear what sort of cost something like that will take but at the same time it’s our job to try and squeeze out all the possible wanted changes as soon as possible early in development when they can be actually done.
