Boilerplate projects
I've been meaning to upload this for a while now. Today, I'll finally get around to it, mainly for my own reference, but also to possibly help other people out.
The scenario:
1) You are asked to make a demo application...
2) ...in as short a time as possible...
3) ...in a pressured environment...
4) ...did I mention "they" want it all finished 2hours before you even started
You get the picture. Nowadays, just because we have Design thinking and wonderful ways of quizzing a business user on how they feel and what they want a Mobile application to do and using all the Agile techniques you can throw at a buzzword bingo board, it still comes down to the basic element. A coder, then has to code something and writing code takes time.
I totally agree that making a prototype / mockup / wireframe app can be simple / easy / quick, but making a "real" application is not so, as there is so much more that you have to construct.
Now, in previous coder world thinking, it was all about "let's make re-usable modules of code" that we can just plug-in and bolt together, yay! for Java. Let the trumpets blare the sound of success.
Unfortunately, in todays Internet-Time, the code you wrote 2 months ago to do "that thing", is now way out of date. It won't integrate with the new version of thingyJS and if you don't use thingyJS, well, you might as well not bother as that is just ESSENTIAL to meet the requirement.
I think it must have been in the early 2000s when non-technical CTOs made that (rather silly, in my opinion) decision that writing code is a menial, robotic task that can be belittled and outsourced to the cheapest person who can search Google/Bing/StackOverflow and hack something together.
Writing code is an art. Like engineering a car. Would you feel safe driving about in a car, knowing that it was put together by the cheapest engineers, who (most likely) cut&pasted code from StackOverflow to meet the insanely short deadlines? No. No, you wouldn't. But, you do, you just don't think any life is going to be lost by it.
Personally, I think it's time for the coders to start to regain their position back at their rightful place.
They make things happen, they create, they engineer, they turn that idea you have into something that is real. But, don't be an ass and expect it to be a full blown scalable production worthy application in 2 days. Oh and pay the wo/man what they are worth for their creativity and hard work, you'll be glad you did in the short and long term.
Those coders, will still need to follow the same coding principles as they always have, the main difference being, the time between Playbacks should be shorter, usually every 2 weeks, that means you need to plan better to ensure that tasks can be completed in realistic timelines and allow for changes in the design. Just because you heard the word FAST, doesn't mean the coders are time-travellers and can magically code quicker, they just need to be given the right information in order to be quicker.
Continuous Integration is often mis-understood as just being a set of tooling that builds checked-in code and alerts coders when someone has 'broken the build'. Whilst this is kind of true, there is more to it than that. It comes back to the 2 week delivery cycle mentioned above for a Playback. The coders will be continuously integrating their code together for that Playback that is coming up, so it is now also wording to describe that process rather than just the tooling.
Boilerplate project using Ionic/AngularJS for Bluemix (nodeJS)
Boilerplate project for Ionic CLI / Cordova
Boilerplate project for MFP Studio (Eclipse)
Boilerplate project for MFP CLI based on Ionic CLI
Ironically, yes, these will be based on specific versions of the products used, but I will attempt to not do anything that is version specific, so it might be of more use in a years time!
The scenario:
1) You are asked to make a demo application...
2) ...in as short a time as possible...
3) ...in a pressured environment...
4) ...did I mention "they" want it all finished 2hours before you even started
You get the picture. Nowadays, just because we have Design thinking and wonderful ways of quizzing a business user on how they feel and what they want a Mobile application to do and using all the Agile techniques you can throw at a buzzword bingo board, it still comes down to the basic element. A coder, then has to code something and writing code takes time.
I totally agree that making a prototype / mockup / wireframe app can be simple / easy / quick, but making a "real" application is not so, as there is so much more that you have to construct.
Now, in previous coder world thinking, it was all about "let's make re-usable modules of code" that we can just plug-in and bolt together, yay! for Java. Let the trumpets blare the sound of success.
Unfortunately, in todays Internet-Time, the code you wrote 2 months ago to do "that thing", is now way out of date. It won't integrate with the new version of thingyJS and if you don't use thingyJS, well, you might as well not bother as that is just ESSENTIAL to meet the requirement.
I think it must have been in the early 2000s when non-technical CTOs made that (rather silly, in my opinion) decision that writing code is a menial, robotic task that can be belittled and outsourced to the cheapest person who can search Google/Bing/StackOverflow and hack something together.
Writing code is an art. Like engineering a car. Would you feel safe driving about in a car, knowing that it was put together by the cheapest engineers, who (most likely) cut&pasted code from StackOverflow to meet the insanely short deadlines? No. No, you wouldn't. But, you do, you just don't think any life is going to be lost by it.
Personally, I think it's time for the coders to start to regain their position back at their rightful place.
They make things happen, they create, they engineer, they turn that idea you have into something that is real. But, don't be an ass and expect it to be a full blown scalable production worthy application in 2 days. Oh and pay the wo/man what they are worth for their creativity and hard work, you'll be glad you did in the short and long term.
Those coders, will still need to follow the same coding principles as they always have, the main difference being, the time between Playbacks should be shorter, usually every 2 weeks, that means you need to plan better to ensure that tasks can be completed in realistic timelines and allow for changes in the design. Just because you heard the word FAST, doesn't mean the coders are time-travellers and can magically code quicker, they just need to be given the right information in order to be quicker.
Continuous Integration is often mis-understood as just being a set of tooling that builds checked-in code and alerts coders when someone has 'broken the build'. Whilst this is kind of true, there is more to it than that. It comes back to the 2 week delivery cycle mentioned above for a Playback. The coders will be continuously integrating their code together for that Playback that is coming up, so it is now also wording to describe that process rather than just the tooling.
Okay, with all that in mind....I've written a couple of pages that cover how to jumpstart your project, by creating boilerplates that you can start from.
So, rather than spending the first 2hours doing this foundation level stuff, you can either download the code and get going quickly or read through the pages, follow along and see how they are made up and can execute the one that you need in 15mins or so. As it's foundation level, you can then start to build in all those nice bits that the business wants to see in the Playbacks.Boilerplate project using Ionic/AngularJS for Bluemix (nodeJS)
Boilerplate project for Ionic CLI / Cordova
Boilerplate project for MFP Studio (Eclipse)
Boilerplate project for MFP CLI based on Ionic CLI
Ironically, yes, these will be based on specific versions of the products used, but I will attempt to not do anything that is version specific, so it might be of more use in a years time!
Comments
Post a Comment