Development

How to make it work

I joined a new team from the beginning of this year at one of our customer. This project is more complex compared with my previous work since it involves more team-members and larger environments. I learnt a lot from this project and I would like to share some experiences that helped me grow.

1. We work closer to the customer.

My previous projects involve very little communications with customers. The customer delivery did most of the work. Differently, the current project requires the customer and the development team working closely. We meet at least once per week, either face to face or online (due to the current COVID-19 situations), to gather the user’s feedback with the following aspects from different locations,

  • User experience on current version of the product
  • Bugs and critical incidents reported by service desk
  • New feature requirements

Meanwhile the development team shows the progress to our customers. In my opinion, it is an efficient way to understand each other in both directions, and this helps us meet the customer requirements in time.

2. We work closer to the different teams.

My previous tasks require me working individually, while this project involves several teams with various assignments and co-workers from different time zones. That don’t cause us any trouble, since we find our way to work smoothly among the teams and individuals as follows: 

  • We start our job with a scrum daily, and it triggers my day by making a proper plan for myself and also keeping track of others’ progress. 
  • People in our team are nice and cooperative, we are willing to overcome obstacles together and share ideas with each other. When I was new in the team, I did the pair programming from time to time with senior members. The pair programming helped me to quickly understand the existing system and new knowledge.

3. We have stricter control of the code quality.

Code quality is important, as it impacts how secure, maintainable and reliable your codebase is. Particularly in this complex project, multiple teams can share the same repository. In order to improve the code quality, we have the code review and do the code refactoring. And I’ve gotten used to the “test-driven development” style, I realize the benefits of covering code by unit tests: 

  • Easy to troubleshoot if the codebase is broken due to a new submitting
  • Easy for others to understand the code being tested
  • Reduce the bugs and design flaws in the early stage

4. We have more comprehensive access to framework features and technologies.

It is always fun to learn new stuff. And I really appreciate that I have such an opportunity to learn AWS technologies by participating in this project together with awesome teammates.

Development

Fullstack or not?

Fullstack vs. frontend and backend separation. This post is about how to optimally organize your team to build solutions that deliver as much business value as possible. This includes the most important aspect, the user experience.

Let’s say you have a team that should build and run some kind of web service that is presented to users both as a web page and an app that exists in the app stores.

One of the questions is how much specialization there should be within the team. Does every member of the team work on everything? Do you have specialization? Lets for this post limit the discussion to developers in the team. Most teams will need specialized roles for designers, testers, project owners, stakeholders, etc but that is outside of the scope of this post.

From my experience there are 2 major ways I have seen this organization happen naturally:

Fullstack or Frontend / backend separation. If having the choice, what way is best for your team?

Fullstack

Every developer works with everything needed to develop and run the solution: the same people do the HTML and JavaScript, down to the (server side) integrations with business critical (in some cases legacy) systems. These systems provide the actual value to the webpage or app.

Fullstack does not preclude having a UX designer involved, that does the design in design tools, but the designer doesn’t do the actual implementations. And in my experience the actual implementation of a design is very significant for the end result.

Pros

A single developer or developers that have high bandwidth communication can work very efficiently on a single feature and deliver it into production with a minimum of coordination and communication. This can be a great advantage if time to market is the most important thing for example.

Cons

As a developer dealing with integrations against internal systems it is unavoidable that you take a perspective of how the internal legacy systems at a business works. This will likely impact user experience.

It is hard to find developers that are good in both frontend and backend. Some developers with lots of backend experience might overstate their frontend skills, and vice versa. In a worst case this could result in a very bad user experience.

This comes from the fact that you will know all the internal complexities. It will leak into the user interface, and also developers will be tempted to cut corners and implement a user interface for the legacy system(s).

Frontend & backend separation

You have some developers that are doing frontend only, that is the HTML/JS/CSS or implement the iOS/Android app code.

Then you have the backend developers that do the “web-back end” that is code that is running server-side in the public cloud or datacenter, and provides the web facing APIs

Each group within the team owns the technical architecture and evolution of their respective part.

Pros

Frontend developers won’t know so much about internal systems and what functionalities or apis they provide. They will instead be able to think clearly from users perspective in every case.

Frontend developers can fully focus on growing skills with web frameworks and new and evolving frontend technologies and app native apis. Same thing for backend developers, they can fully focus on building maintainable and operationally stable backend API:s.

Cons

It is less efficient to deliver new functionality into users hands. More coordination is needed to make the solution work within the businesses constraints and current capabilities, and at the same time implement the user experience that is optimal.

Some developers will find this way of working less satisfying if they are interested in both frontend and backend technologies.

Conclusion

In my experience, if you prioritise user experience the highest, like in the case if you implement a B2C solution, frontend / backend separation is best.

If User experience is not of the highest importance, or if your target market is “power users” that to some degree know the internal workings of the business. This is more common in B2B scenarios. Fullstack might be best for your team.