Let’s talk about Production Level Apps
The hard facts about building for production.
Premises
I’m pretty sure we are all building something, and some are still thinking about it, but one thing we’ve come to love is the process of actually building products as developers.
But then all processes must come to an end, this is when everything we were taught about closing a project and making sure production is a home run comes into play.
But wait, nobody ever taught us about production in school right? Yea thought as much, production is a different ball game altogether. Eventually, when a project hits production, its assumed the coders stopped playing and switched to the god mode (big fan of dragon ball Z).
In an age when everyone expects their perfectly brewed latte to be done at the snap of a finger, production has become this idea of a system which has been built to be flawless. Meaning no downtime, every feature working perfectly, making sure the UI is golden and paying design massive respect to design and experience.
Many don’t realize how much it shifts from being that thing you do for fun into becoming a chore. This is a problem I faced at work, practically held down an entire feature base, simply because of the transitioning process. Which usually involves developing a liking for standards and coding principles ( which one must live by), learning to double check and possibly triple check, understanding the importance of packaging commonly used UI components, as external components, Organizing debugging and coding times (trust me these are not the same), Making sure to stay alive and stable, especially if you are the kind of developer who still works on outside jobs.
In the end, it all comes down to ideas which the team as a whole must have in mind, be it the designers — working the experience, feel and flow or the developers bringing things to life.
The Ideas
In order to get the idea across, I’ll love to review my experiences and what I learnt from them with relation to production level creativity and process.
Making it work
This was a hard one for me to really understand, but it came down to this essentially, your code is for the user, therefore if it looks nice, but doesn’t work nice, its otherwise useless as a rock. This is not to say that you have to focus on functionality above all else, but its partly the case. All the coding standards wouldn’t help if it doesn’t work.
Making it work in a nice way
If it looks nice and works okay, it could still not be enough, cause the loader icon isn’t displayed or the padding is too wide. Sometimes it just gets as flimsy as these, frankly they piss me off all the time, but when you think of the user, for example, think of yourself using a tool such as Google. Their use of convention even in design has a kind of uniformity that gets to the products being designed and created most of the time.
Taking a close look at all of their apps and products, the designs are eccentric and if I’d likely say they are uniform in structure and flow. This is what a design style is and most startups have to adopt this. Design is key and it’s not just about look its also about feel and everyone needs come to an understanding of this. pretty much why we see many preaching UX. Its because it’s important.
Yea some may have raised eyebrows going like,
“come on its google, they are supposed to be like that”,
Yea yea, but the truth these days is the fact that everyone’s got to be like that. The MVP (Minimum viable product ) ain’t what it used to be (here’s a cool write up on that ). It’s now much more. Let’s go a little bit in-depth.
For those of us who are not familiar, here’s a modern definition of the MVP, permit me to quote Eric Ries.
“The minimum viable product is that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least efforts”
In essence a minimum viable product is a bit more like a Minimum Awesome Product. So even for the newcomers, the bars are high.
Organization than Code
With production in mind, right from the first day, its all about organization than it is about code if one discards the process of ensuring the organization of the platform, in terms of work process, workflow, team understanding, as well as convention, styles and other mind-numbing things (like stand-ups). In due time it tells.
Sooner or later we come back to it, cause its more than just the design and structure but even more about organization.
When we think about organization there are a lot of ways to look at it, and even a whole lot more it concerns. Some of these ways include
Organization of App structure
In due time is becoming clearer that there are somethings you should not leave to the developer to decide, If not disciplined enough a developer would most-likely pick the tools he wants to learn, not those he’s already fully used to. This needs to be coupled and with both sides of the development, the developers, the designers and the project managers. Projects need to be reviewed continuously to ensure the stack is actually appropriate for the task.
Feedback Structure
Most of the time as much as we’d like to have completer finishers (interested in knowing who these are, check this out), making up the most part of the team, chances are they are not all finishers and therefore it’s important you consider your feedback tunnel. Coders often work amiss and sometimes (most times maybe) it can be annoying. That’s why the feedback loop is important. There are a number of ways to always implement this and make sure they get the gist.
Conventions over Configuration
Yea some of us already know this, for those of us who are not familiar with the term, its a software design philosophy aimed at minimizing the number of decisions a developer is required to make while building software, its been used in many of the applications and tools we use today ( and guess what, these are in production.).
Take Laravel for example, when you decide to create a new model for Products, the table name would be called products by default, this is the convention, so you don’t have to think so much as to what to name your tables. Now that’s convention, more examples of this can be found in many different parts of the laravel codebase, If you wanna know more about this check it out.
Style guides and Reusability
Yea this can be a derivative of the coding by convention principle, but this is meant to ensure that everybody’s code is similar.
Kinda reminds of a time I was asked to build an api for a section of a platform and I built without knowing that they had a set guideline for api creation and set of traits and packages that make it a no-brainer, but when I was done, it was way different from what they had. And finding out, I proceeded to refactor into their system, and guess what?, It was way easier to work with, cause they had patterns which made it’s easy to know what to do in any situation, and the resuability was on point.
Chances are the codebase would use a lot of the same things in many different places, why not just abstract them.
Now lets look at the ideal process of doing things.
The Ideal Process
Well I can’t say I know what this is, but heck I’m writing about it so 😅. Well many have different views of the same non-controversial topics like spaces vs tabs. and I can pretty much say the same is true of this topic but here’s what I think is ideal based on experiences and research.
Onboarding Process and Breathing Space
When new developers join the fold, they need to be properly educated about what your stack really entails, and you know what this means, so much more emphasis on documentation.
Yea I know a lot of us do not like writing documentation, but what the heck I still don’t like writing docs, but its probably the most important part of any software design process, asides building the damn thing right?.
What’s more, the first point of reference for any developer on most projects is the documentation. It a major factor in making some key decisions and its the main reason many would choose a certain tool over another. The easier it is to understand the better.
What’s more, the on-boarding process is a whole lot more than just introducing them to the stack, its more about introducing them to the process and ideals of the team they have now joined, even if they are contract based developers or full employees.
Usually, it can all be outlined in a trello board, once saw a company do this for its sales staff, (I remember now, It was hotels.ng), Interestingly trello has a feature board like this, check it out. It’s a good way to simplify and make things easier to work with.
User Stories and Epics
A lot of companies are getting this right, a lot aren’t, there’s always something missing in the tools being used, but the task must be done. And its important with an absolute emphasis on important that the ideas of a feature be clearly outlined in terms of functionality and how it would operate down to the smallest details.
It’s hard to really do this. But for any successful project, it’s important to really understand this process. hmm, maybe I should have titled this scratch to finish or something like that , but anyways, its much more than we usually anticipate and yea new ideas may come along, but what one must understand is that code is hard to write, and a whole lot goes into the process, especially when its built with a structure in mind.
A couple of tools that help get these out of the way would include Trello, Atlassian’s Jira, Pivotal tracker and many more.
Emphasis on Soft Skill
Developers are a crazy bunch like really fucked up crazy, and yea you may have the best in the market, but a developer is only as good as his process.
Let me clear the air on that. You might want to believe a developer is spending more time on your project than any other, may be true, but the fact always remains that 95–100% of the developers you have, would have side projects.
Now side projects are not bad, heck StackOverflow was a side project. But how we deal with this is pretty damn important, the products people build make things easier and better, so it’s not exactly ideal to ask them to sacrifice their passions and ideas for that of the company simply because you are paying them money.
Yea that’s on their own time, but a better strategic measure to keep refreshed and satisfied, with the aforementioned facts its pretty apparent that if these were implemented well they can deliver faster, but its more about soft skill, which they need to be taught it simply comes down to encouraging them to manage their time better and know how many things they can actually take on at a time.
Pipeline and Feedback
I think this is the second time I’m mentioning feedback, but yea its pretty damn important, The pipeline is the process via which your code is taken through the deployment system, tested and reviewed before making it fully accessible.
This is where technologies like CI systems come into play. These include systems like Travis CI, Circle CI, Bitbucket CI, Gitlab CI, Jenkins and a whole lot of CI systems. With respect to mobile application development, here’s a good resource to check out concerning CI systems.
CI and pipeline is important and I could go on and on about them but its important to understand their importance, When you have a team of developers going at each other’s codes like ninjas on steroids things are meant to get broken (have you ever seen ninjas leave a place without blood in their wake?), and CI balances the show like Thanos, with good CI systems nothing gets past the filter and you can make sure to test appropriately against several measures.
So yea its a good Idea to invest in the DevOps side of things.
Another system deeply ignored is unit testing in development. To be truthful many are scared of it, Yea, If unit testing was done appropriately then a lot would be averted in the process. There are many resources for unit testing for the many different stacks and frameworks there are. And it’s important to take real advantage of this.
Conclusion
Production level development is a different ball game entirely and many are not even sure they can keep up, but its important to do things right, if not we’ll keep on having lots of stillbirths in the industry, It all starts from the beginnings and its important we understand that there’s a really long way to go.
Good process is all there is and what it all comes down to, it’s not just about the development but also about the design, the ideas and the intricacies ( little things we think don’t count).
Good Products are accumulations of well refined process, they are not random
One Last Tip
Don’t be afraid to invest in the process, it would save you a whole lot of stress and make everyone happy, and help you avoid a shitload of unnecessary work.
I guess that’s all I have to say, for now, feel free to drop you heart piercing comments below, I’d love the feedback.
Thanks for reading.
