jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

Project TD - Day 19 update – Moving from Requirements Planning to Design

[Ongoing series of blog posts to inform potential developers, users and (hopefully investors) about this new app ecosystem I am architecting, designing, developing and deploying. More details at this page]

Aha! It took 19 days for me to wrap up the requirements planning. I have been using the whole Island – Volcano – Ships and other stuff – Ocean as an example for my ecosystem. I think that makes sense because everything that happens in software (or any machinery) for that matter is a reflection of real life itself. That is why, it is only prudent that I (with my limited intelligence and even more limited imagination) use some real life stuff, especially nature stuff, as an example eco system.

Right then, enough with my babbling. So, the requirements planning is done. A huge chunk of details related to this is documented at this link, creatively titled, Requirements Planning. Of course, nothing is ever done when it comes to any planning. Yet, I am happy with the stuff documented so far. I feel confident enough that I have enough stuff to move to the Design stage.

The design stage will be elaborated upon I future blogs posts. May the force be with me.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Project TD - Day 19 update – Designing the Design Process

[Ongoing series of blog posts to inform potential developers, users and (hopefully investors) about this new app ecosystem I am architecting, designing, developing and deploying. More details at this page]

Now that the requirements planning is all done (at least to an acceptable level), it’s time to finalize the design process. The design process is crucial. I have always believed that being a developer (which include being a designer) is always better than being a programmer. I have spent considerable ink on that topic while discussing Uber and self-driving cars. That means, a good design is the only way to ensure that the idea leads to become an usable service.

That means, I need to first design the actual design process. My design for the design process would include the following four components.


Technologies To Be Used



Everything in software development is a cyclical process. The more time you spend revising stuff, the more you find flaws in it. The less flaws one finds, the more confident one becomes at its design. A solid design means less flaws during actual development (where the actual app ecosystem is coded. I always make sure that I run my design through a lot of people. God has blessed with access to individuals from varied backgrounds, and most of them are people who know the techie kind of person that I am. So, when I approach them with what I want, they don’t get weirded out or act surprised. In other words, I can collect an endless amount of feedback from folks who are tech wizards to those who technical achievement is forgetting their personal phone’s PIN LOCK.


It all starts with illustrations, drawings, doodles and anything else one might call creations. I have given myself access to a lot of drawing tools. I have got the good old fashion pen and paper. The premium notebook for scribbling. Of course, I have my iPad with a nice Amazon Basics stylus. In the future, I will probably invest in more expensive drawing tools but I must balance my ambitions with the budget for this project.

One reason to start with sketches is the universalness of visual things. My mother can understand. My students can understand it. My tech mentor can understand it. Random people I meet on the road can understand it. Anybody can understand it. Over the years, I have learnt that no feedback is less important. Sure, some feedback might be useless, but then again, the greatest products have been built by the silliest of inspirations.

I have already concluded that the app ecosystem has the API Engine at its heart. The API Engine is but a collection of APIs, and each API would have a design connected to it.

Technologies To Be Used

Once a sketch has been finalized, the next step is to start adding real technology to reflect the corresponding actions. I mentioned earlier that that each API would have a sketch attached to it. Once that is done, it would be essential to connect the different components of the sketch to the technologies that are used.

For instance, at its simplest, I would need to build an API service that would take some data, and push it to the database. For this, I would need to code the API, put it on a server, design the database and then connect the two. I would need to list out all this, and code the stuff out of it.


Me just learning how to convert the sketches into actual technology components is not enough. I must write tutorials related to it. While I am an architect, I still make a huge a chunk of money through training. I must have a collection of tutorials that will help me bolster my tutorial portfolio. Otherwise, one of the main benefits of this thing will be lost on me.


Of course, all code must be pushed into a public repository that supports tutorials. A tech tutorial without supporting code is not that cool. I will be the first to admit that I myself have written multiple tutorials that don’t link to a code on the repo. It’s a fault I am trying to fix going forward.  

Each design will go through the above steps, and hopefully there is enough for room for all possible flaws to show up. The end result of the above process will be modules, which I would like to consider as ‘ready to use module templates’ or RTUMT. The actual development process (which comes after the design is over) will utilize these RTUMTs. Hopefully, since the RTUMTs have already been vetted at the design stage and the coding stage, the actual development will put a lot of focus on integration of these modules, continuing my efforts to keep the entire design modular. This will allow me to remove and replace modules as newer and better technology should become available if the app ecosystem survives the first year of operation.

Of the five stages of the app ecosystem development, I imagine that the design stage to be the most extensive. I have vowed not to start the actual development (which will eventually lead to the beta launch) until the entire design is completed. That means, if necessary I am happy to spend an additional 6 months fine tuning the design rather than jump to development with a half-baked design.

It’s going to be a long ride man.

Genius is eternal patience - Michelangelo

Follow me on twitter, facebook and instagram for more updates. Thanks!

App Ecosystem – Day 1 – Naming the project and beginning things

Yesterday, I wrote about finally beginning to work on not just an app, but an entire app ecosystem. As with anything, everything starts with giving it a name. A name is everything isn’t it. In my earlier post, I spoke about the relevance of meaningful names making code. If I am the kind of guy who spends so much time simply naming a basic variable in a simple piece of code, I should give a proper name to this app ecosystem as well.

While naming, there are two types of name. There is the placeholder name, and there is the actual name that you use for marketing. As an independent businessman, I must appreciate and more importantly respect the value that marketing brings into day to day business activities. So, for now, I don’t have an actual marketing name for my ecosystem. However, a placeholder name, I will go with would be ‘Project TD’.

What TD stands for, should remain in my own head for now. I am weird that way ;)

Moving on, any app ecosystem, especially a technology system, should and must follow the Software Development Life Cycle. Sure, a guy like who hate using established systems such as SDLC. It’s boring, and it sounds dull because some folks designed such things, and they were probably not cool. I almost always take the road less taken, the uncharted island attracts me more than an established. However, I admire and respect what others have done, cool or not cool. Respect must be given, where it is due, no matter how much I might not like on a personal level.

So yes, TD will also follow the SDLC cycle, but I will make changes as necessary. A development model that does not adapt to changing scenarios is a dead one. I don’t want my development model to die, obviously. Here is the standard life cycle that I will be using.

  • Prep work – includes risk analysis
  • Design – loads and loads of drawings and diagrams. Also includes presentation, mostly to non-tech people.
  • Development – Loads and loads of typing. Referencing external sources, books, mentors. 4 monitors, with simultaneous coding on at least 2 computers.
  • Testing – Engaging with lots of different types of users, everybody from tech savvy users to folks who are turning on computer for the first time. A true architect and developer never forgets his users because that is where the money comes from.
  • Deployment – Including a lot of security stuff, discussing encryption systems and networking realities.
  • Repeat and Rinse.

While all this cycle stuff is happening (or will happen), perhaps the most important question is why do all this? More importantly, why do this at all?

The answer, it boils down, to the simple life concept of ‘show, don’t tell’. Even when I was a kid, I preferred to show stuff, rather than explaining stuff. Interacting with the five senses is perhaps the best way to get some work done. This blog (and all the other things I have done and shown for the past five years) has helped some score some serious amount of deals, and that means colour green. While I am already designing end to end solutions for clients, I am yet to train people on end to end solutions.

Posts such as this one, and many more that will follow, will help me keep track of progress. As always, I also hope that some of the things that I write on blog will help others who need information. Hopefully, at least one of these goals will be achieved.

Follow me on twitter, facebook and instagram for more updates. Thanks!