We are defining a framework to ensure product development is scalable and on track. From on-boarding, problem decomposition, status tracking to solution construction.
A product is something tangible, e. g. a painting, music or a software ecosystem, that is an extension of the inner-most truths, of a team or an individual.
If you are interested in the social perspective of a project — check Self-Aware Software Artisan: Team.
📹 Intro video: Charles Bukowski — Style
🏆 Your progress 🌏 🏄♂️
After you’re done reading: check the ⬇️ bottom of the page — you’ll find next parts of this series that cover diverse set of related topics!
📣 Coming soon!
I’m continually refactoring this series.
Subscribe to receive a single-page Manifesto: Scalable Software Development distilled to the ultimate truths; from the viewpoint of an Software Artisan.
Author’s experience
Data Sculptor, Architect of Systems and Products.
Founded startups in the fields of Education and Sports and led teams of up to ten people.
Worked, as a Systems Architect, Frontend, and Backend Developer, for a product company, a digital agency, and as a remote freelancer.
For more information, check my Personal Website.
🎷 Background song
Preparing product for the success
- Everything is important — prioritize, but know repercussions of any compensation you do,
- re-think your idea until it becomes at least 10x better than anything on the market,
- know the main problem you’re solving,
- know surrounding pillars of the solution (surrounding features that are needed to hold the product together),
- find technology solutions to the problems,
- find people capable of solving the problems; manage them in the most optimal way (know your team, know how to pick new members and onboard them properly, know how to handle when someone falls out) (Check Self-Aware Software Artisan: Team Artisanship),
- run everything, from the first day, to be asynchronous, remote-first,
- document everything in a readable and extendable fashion: tasks, code, wikis, git commits,
- have tasks in a single place (ultimate source of truth),
- have outlined weeks, months regarding any work you need to do — known in advance and accessible to the stakeholders,
- have meetings to celebrate or debug problems, only with the relevant people,
- focus on having the Code in tip-top shape,
- continually update the product to improve user interaction and feature cohesion,
- have analytics in place to validate user’s movements throughout the product,
- have available pictures, GIFs, videos of your product, landing pages polished — so when you get that one person to land on your site — it will be as understandable as possible.
Essentially — you are mitigating the problem of being misunderstood. By your team and your users.
You are trying to explain yourself (as a person, company or the product) in the moment, and in the future so that people get back to your product again and develop a relationship with the thing you’ve built.
Avoid debugging on Slack— have your tasks in a single place
Move all of the communication to your task tracking software.
You never know who will need a snippet of your conversation for a specific problem. Do them, and yourself a favor — move communication to a single place so it can be easily viewed by others in the future.
If you had a conversation over Slack or other chat software, move it to the Task tracking software upon conclusion, with all-important corners you’ve taken in the conversation.
Document in English
Write everything in English, even if you are from countries where English is not the first language.
This is generally recommended for easier scaling. Having everything documented in English (documentation, tasks, comments, git commits) will prepare you for it.
Constantly updating the status of the project
Tasks, milestones, documentation — everything needs to be accessible at any time. So, when you pick the project up in a few days or weeks, you will know exactly where you left off.
Tasks need to be documented from A to Z. Every corner case of it needs to be explained in the task at hand. Every advancement needs to be documented there. If you chug up a new view on the task during a meeting — write it down in the task.
Tasks need to have a hierarchy, so they can be traced from top to bottom.
It may seem like a lot of overhead, but it will save you a lot of time down the road; and that’s what we are looking at here — long-term optimisation and balance.
Meetings — defining goals; relevant entrance, and exit of participants
Audio or Video meetings are there to share the joy and discuss any hard-hitting problems.
Meetings need to include only people having a true stake in the topic at hand, the rest of the people need to drop out and focus on whatever else is on the priority list.
Optimizing performance — sprints and cool-down periods
The Company wishes to optimize human performance. That is surely not done by having sprint after sprint, for a year or two.
It is a marathon.
Introduce cool-down periods for recuperation, so people can recuperate from the killing sprees.
Plan and review on multiple scales (daily, weekly, monthly, yearly).
e.g. 2 sprints, 1 cool-down period.
Each lasting a week.
Optimizing performance — Giving or taking tasks based on the emotional state of the individual
Sometimes a person will be more effective refactoring the code, than working on a new feature. It depends on the person outside of the work — its physical, psychological and sociological state.
If you have the data about the emotional state, given to you con-sensually, by the person — you could optimize output much better than ramming any type of issue to a pseudo-random person.
Don’t micromanage — give trust, demand, and expect the best from the people
Know the state you wish to get into with each person, the team, and the project — on a daily, weekly, monthly, and yearly scale.
Clearly communicate any determined scope with the stakeholders.
Prepare everything in advance: tasks, wikis, any other inputs — i.e. have your next week unwind itself naturally. The need to micromanage and interject needs to be minimized. Less wasted time on Slack, fewer interruptions, more deep work, and more effectiveness from the whole organization, scalable throughout time.
When the framework is known for any aspect of the work, you can easily measure and adjust where and when needed. Communicate to people clearly and leave them alone. Expect them to do the best work of their life.
Scalable Apps: Picking the technology and the tools
Pick the tools, languages, frameworks that together:
- allow to write scalable code by design (e.g. TypeScript instead of PHP)
- will be popular and useful in the future — times change, tools get deprecated — pick what makes sense long-term for attracting a right set of people (e.g. for the backend: you are better off with Node.js than PHP).
For most use-cases, I would recommend using a UI framework like Vuetify — this will handle UI (buttons, tables, fonts, relative relationships between the components (size, colors, …) so that you don’t have to write CSS. Focus on writing the logic, not styling buttons.
Scalable way of building:
- document your code (firstly: through the code, secondly: with comments, thirdly: through tasks)
- write your git messages as essays, with a straight-to-the-point summary in the first line
- track every feature, bug, thinking you have through tasks (JIRA, Trello, Asana, GitHub Issues, GitLab, …)
Check “Self-Aware Software Artisan: Code Artisanship”.
Technology palette for your stellar, enterprise-grade Web Apps
A palette we use @AndromedaTechnology:
- General language: TypeScript,
- Backend: Node.js (Nest.js, Koa.js) with TypeScript,
- Frontend: Vue.js with TypeScript,
- Database: MongoDB,
- Event-tracking: Kafka,
- Backend-Frontend layer: GraphQL,
- Search Layer: ElasticSearch.
Product Development Example: Status and Future Development of Habitus
Habitus App
- Live site
- GitHub — Frontend (TypeScript, Vue.js, Vuetify)
- GitHub — API (TypeScript, Koa.js, MongoDB, Jest)
- Medium
API Status
- Used to show initial data on the frontend,
- [Emotions, Habits] CRUD (Create, Read, Update, Delete),
- admin can CRUD,
- guests can read the data,
- tested (Jest, MongoDB InMemory Server),
- technology: TypeScript, Koa.js, MongoDB.
API TODO
- Saving encrypted user data,
- seed more initial data (emotions, habits),
- implement teams.
Frontend Status
- Features: emotions, habits, notes,
- standalone client,
- can be used completely without the API,
- offline-first,
- saving data only in your browser (localStorage),
- getting initial data from the API (if available),
- Progressive Web App,
- technology: TypeScript, Vue.js, Vuetify, Vuex, Axios.
Frontend TODO
- refactor few components (GitHub Issues),
- passcode / PIN access,
- encrypt data in the localStorage,
- sync encrypted data to the API,
- implement teams (API),
- implement system creation (habit constellation),
- improve the UI.
Use and join the development of Habitus!
Find this useful?
👏 Clap so more people see the story.
❤️ Support your friends and colleagues at work — share this essay with them!
🚀 Use it as a, Company or Personal, Manifesto! Fork and Adapt on GitHub!
🏆 Your progress 🌏 🏄♂️
Product Artisanship — ✺ You are here.
Code Artisanship — 👈 Next up!
Top comments (0)