Photo by rawpixel.com
We're going to discuss some un-nerving concepts during this explanation that may turn some stomachs so feel free to back-out now! Keep in mind that the following suggestions are for self-driven projects and not to be applied into a team dynamic.
Also, as a precaution, this article was meant to adhere to the simple reading guidelines of a blog post, however reaching the end, it seems that dictum has been severely over-reached.
- Appropriate planning and segmentation
- MVP Prototype (plausibility)
- Distribution of major checkpoints
- Grit, grit, grit
- Sprint for the finish line
Appropriate planning and segmentation
The first thing thats important is get a good image what the finality should look like. Try identify your own list of obtainable contract items. It should be capable of
z by the end and give yourself a loose time-frame.
Breaking the subject up into consumable pieces. This is going to be a hard topic to articulate however, for this case lets use an example.
Say our project of choice is a School student grade/attendance tracking system, so for this objective we'll want to identify a final interface, database layout in consideration of full functionality. For simplicity of the article lets say we want it to have the following.
- Users (details, login, contact)
- Students (details, attendance_xref, grade_xref)
- Staff (details, employee_xref (if we decide to dig down that path))
- Parent (details, student_xref, contact)
- normalized tables for (attendance/grades/events)
Now that we have our segmentation, we can start splitting up the work.
- Identify the framework to be used
- Build-out a lose schema
- Database integration
- Tying in the framework
- Build out a mock interface [per feature]
- Make the interface work [per feature]
- Repeat for all steps of functionality [on feature].
Okay, that'll be enough on segmentation, this is enough to make me bored of reading it as I'm writing it, more meat & potatoes.
Minimum viable product (plausibility)
Now as much as we want to indulge in additional functionality such as notifications, password resets, additional security. We must refrain for a second iteration of features and benefits of the product.
For the purposes of a prototype, its better to prove our concept and its ability to do what we want over providing a feature rich feature set.
Just remember for this part, think of getting from A to Z in the most efficient way possible without sacrificing of the underlying idea.
Distribution of major checkpoints
Typically this is the point where you start making (epics, stories, tasks) in association with each critical part. For the exercise we've illustrated in this article. Lets do that now:
Identify the framework to be used: This portion would be mostly research and development, once we've identified the best possible frame-work to use then we'd do some quick follow-up research into some best-practices using said framework.
Build-out a lose schema: The mass majority of the architecture needed for the project will be planning how how to modularize the data sets. In these situations a work-flow diagram and even a SQL visualizer may help.
Couple of decent visualizer I'd recommend would be:
Database integration: If you decide to use an ORM, that's often preferred with doing much with OOP. In either case, consider any abstraction needed for common operations. In our illustrated example we'd want CRUD operations on Users, Students, Staff, then again on events such as Grades, Attendance, Events.
Tying in the framework: Sensibly we've been adhering to these best practices the entire time we've been building in our abstraction layers for the db and for the operations. So this isn't typically a chronologically strict member of this article however its best to keep in mind when progressing linearly through the project.
Build out a mock interface: This will be done for each aspect of the project. If we're just building an API then its simply the contract we'd want to uphold. However if we're building an interface then its defining the requirements satisfying the appropriate forms, then to adhere them to the operations or functions we've setup in our controller.
Make the interface work: This is partially covered in the previous segment, but this is more specific to the UI/GUI/WebInterface where as we've built out the design (I'm typically lazy so i'll stick to the safety grounds of Twitter Bootstrap. But that's just me. Then allowing those to bind to the API operations we've defined.  Lets not forget about security!
Repeat for all steps of functionality: All these operations we've just described should be repeated for all the steps we've identified in primary checkpoints.
Grit, grit, grit
Since we've itemized the plan out sufficiently by this point, the next part will be to methodically attack each category with the methods we've outlined.
This portion can be monotonous and grueling at times. But if it helps we're free to jump around to break the monotony, especially if you've problem with dedicated attention as I do.
Sprint for the finish line
Once you've made it successfully through the bulk of the task, you should have some loose ends to tie up. Things you've skipped for the sake of first iteration. Do those to see your prototype fly.
Prototyping is a great way to prove an idea beyond just functionality. It gives a great scale of reference for expectation of time totality.
Prototyping also lends towards giving a pretty accurate economical outline if the project involves acquisition of potential hardware.
The other benefits could range between (proving something is even possible) to (showing the big boss that an idea is worth pursuing).
Security should never be an afterthought however when rapid prototyping it is important to the integrity of getting the project to its initial finality before we go back and have a "Security Phase", otherwise security doesn't help a project that never makes it past prototype stage. ↩︎