--Originally published at Debugging My Mind
I like correlating what I read with my own developping experiences, trying to notice what I’ve been lacking, what I’ve been doing and how it can be similar to what the book refers to and finally, what I’ve been doing wrong. The last one tends to come up a lot in the scholar environment, as a lot of times we strive to get things done in a certain way or period of time and with a different incentive compared to a job (having the reward only be grades and learning instead of monetary compensation) which lead us to a lot of mistakes and complications.
When it comes to a quality assurance plan, we most definitely aren’t used to make one, we usually only do proper testing once things start breaking or when the functionality is “completed”, leading into a bunch of work fixing and dealing with lots of bugs.
A really detailed plan seems very necessary for big projects, ones that will be on development for a long time and require the utmost efficiency to be on proper schedule and budget, but I don’t think this will be the case for all projects, it feels like the book, while mentioning a lot of the tools for developping these plans (like taking in consideration defect tracking, unit testing, source-code tracing, technical reviews, etc.) it doesn’t mean we have to apply every single one of them, meticulously in every project we work on, I believe the goal is to learn to sit down, analyze the problem we’re solving and what we’re developping and choose a good schedule of how quality will be checked and assured throughout the process, which in essence, becomes a plan, a quicker one it may be, but a plan in the end.
As we go into projects that involve multiple people, it definitely becomes necessary to record everything we do, since most of the times I think the biggest problem ends up being communication. Did someone fix this already? Has somebody noticed this bug? Is anyone working on this particular thing? All of these questions can be answered with a plan and proper communication. Maybe scheduling bug fixing to particular days, update the project management tool that work has started on a specific problem, write down bugs that have been found and if they have been fixed or not and how much time it took.
In the end, I believe a huge document that very thouroughly noted down every tiny bity detail might be way too much for a lot of projects, reserved to that extent only for very big or continous ones and it’s important to also consider that, how are we gonna tackle a task at hand and how much detail does it truly need? I also agree with a particular thing that keeps being mentioned, if a documentation and plan is made, if a schedule is created, they are for a reason, they should be followed and not ignored, what’s the point of using a lot of time into planning if it’s only to be scrapped and disregarded, thing I feel can be common in scholar projects.
After all the QA talk, we dive in onto System Architecture and oh do I think this one is important, I think the word itself is what should describe a Software Engineer and a programmer, the key difference, we are to have the technical and logical background to be able to design the solution to a problem. To not only make things work but have a reason for them to be the way they are, be it scalability, compatibility, performance, among others.
Most systems don’t exist in a secluded environment where they don’t interact with others, where everything will be perfect as long as they stay in their little bubble, that’s why we need architecture, not only that, but because the big system in the end will be made of smaller subsystems that handle different tasks, should one thing break, why should it mean the whole application stops working? (unless it’s a critical component for the whole application’s functionality).
Thanks to notation like UML we’re able to create diagrams that can be understood by anyone who knows the notation, making the design readable and easy to implement, which it should be, since the goal is to make an almost series of steps of how the system works and will be created, not to make a super complex mess that only the architect will understand.
While I believe there will be a class specifically orientated to this topic (or at least I hope there will be), there have been some considerations on it on others, where we have to start getting used to minimize dependencies, separate tasks, be able to make changes with ease, all good practices that lead us towards the path of being able to be good architects down the road.
Programs didn’t use to be made with the thought that they would be given maintenance in the future, compared to today’s software, running old systems ends up being a complicated task, needing very specific environments and conditions, while newer software is readibly patchable and adaptable to the future changes, it’s a living proof that it has become an important point in software development.
