Improved slides development
process - proposal

Current issues


  • front-end developer needs around 4 weeks to build a slide from scratch
  • we have 4 slide makers in the team, it equals to 4 new slides per month
  • with such efficiency level we can't deal with requests number predicted for near future


  • developer environment is far from that it can be called "stable" and "well organized"
  • spontaneous system crashes (backend & frontend)
  • unstable develop branch
  • pre-publish chaos
  • it just does not help when you are struggling for finishing work before the deadline


  • making a slide is not as easy as a pie
  • slide maker has to do much more than just create a view and interaction logic
  • average front-end developer can't handle this task (we have to look for people with special skills)


  • we have far too small common library of reusable components and utilities - when making the slide, developer has to create basic things first; even if they have been made already, nobody knows about it
  • our internal front-end framework is not prepared for some slide-specific features and things which are coming - more and more workarounds everywhere

How slide development looks today



Parsing data

Creating view & interaction logic

Applying filters on data

Creating basic components

Fixing view for export

Fetching data from DB

Front-end developer has to

  • understand data
  • understand aggregation logic
  • know export abilities*
  • finally - know, how to
    create the view

* does anybody know it?

Improvement proposal



Fetching data from DB

Creating view & interaction logic

Creating view-friendly data

Providing filtered data

Improving export

Slide makers

Creating common components

Core team?

  • backend developers has to actively participate in the process of creating slide (preparing data, improving export); that work has to be planned, not ad hoc
  • core team does not have to be separated team, just a people with time given for building components for everybody else, not just themselves

Make people responsible for what they can do well

Stop making people irreplacable 

  • the view cannot be private property of single developer anymore - consider work splitting
  • architecture design have to be consulted with the team, then documented
  • structure as well as code style have to be standarized
  • documentation at least for crucial parts of the code, like modules and data flow, also for not obvious or unclear concepts
  • code reviews and refactors are the only way to make and keep code quality high

Plan the work

  • estimate new slides not right before starting development - give a time for thinking
  • decide, what parts may become common components, then split tasks between slide maker and core team
  • set deadlines and synchronization points
  • track progress to have a point of reference in the future
  • describe each task on bugtracker

Use GitFlow truly

  • feature and bugfix branches always, for everything?
  • develop branch has to be stable and well-tested always (make tester's life harder? start using Pull Requests?)
  • clear and commonly-known releases flow

It's happening today

  • we are trying to estimate slides as a whole team
  • we split work on slide between multiple developers
  • we have a developer dedicated for export feature
  • we are trying to create components with next slides in mind (menu, footnotes)
  • we are trying to work with feature and release branches

We still do not

  • plan tasks in advance, including frontend and backend  job
  • make code reviews
  • write documentation
  • stabilize infrastructure and working with Git
  • plan a time for creating common components
  • keep an eye on Redmine




Slides development

By Eryk Napierała

Slides development

  • 1,110