Published on February 12, 2019
Late last year I had the pleasure of helping a team of students build a prototype for a non-profit here in Auckland. The non-profit needed a prototype to raise more funds and get feedback on their plan.
I’ve helped run teams and mentor junior developers in large organisations. It’s much easier because the support, tools, frameworks, systems of the organisation are already available. For this project the student teams had a blank slate and had to decide on everything from how they would communicate with the sponsors to how they would host the software.
I wanted to write down what I learned and note some of the mistakes I made so that I have a framework for the next time I help new developers!
There were four students in total split into two teams. The students were in their final year and had built some web projects as course work. One had maintained a public facing website but otherwise they hadn’t worked with clients or customers. When I first met the students I was completely blown away by their positive attitude and decided to help right away.
The whole team were enthusiastic and passionate about software development. They cared about their community enough to choose to work on a non-profit project). They all had strong drive and work ethic - each worked a part time job (sometimes two!) in addition to university and this project.
I was acting as a kind of technical consultant and I spent roughly 4 hours a week on this project. I saw my role as helping
I had ensure some best practices were in place and guide some technology choices. I also helped once or twice when the students got really stuck on something but that was rare. They were great at googling and figuring stuff out.
The sponsors wanted to get as much done as possible in three months and the students were very optimistic about development time. The first thing I helped with was limiting the scope and settting realistic expectations for both the development team AND the sponsors.
The sponsors had created a comprehensive specification in Excel with a “Must have” and “Optional” tag on each feature item. The product would be a marketplace with all the customer and administrative features you expect on a mature service like Shopify and the students were agreeing to complete most of it for the three month cycle.
I just didn’t think this was realistic with a team of new developers.
We applied some lean principles to figure out the most important features to test and to order them by priority. This limited feature set would only to take the non-profit to the next step rather than build out a fully featured marketplace.
There won’t be any communication norms like in a mature org so you’ll have to set them up. The project sponsors wanted to have a weekly get together with the students to catch up which was perfect. We initially organised our meetings over Skype and chat but quickly changed to regularly scheduled Google meeting. Every two weeks roughly, the sponsors and students would meet in person in the university to review progress.
We also did lots of communication on slack. There was a separate slack channel for #tech that didn’t include the sponsors. There were discussions that needed sponsor input that had to be moved to the #general channel with far less context and the sponsors would have had a better idea of the work, progress and complexities if they could see all the discussion.
For a smaller group like this it would be better for everyone to be in the #tech channel.
Most web projects need source control, hosting, back end tech, front end tech and a data store. I suggested that the students do some research before deciding on technologies so they looked at
The students also wanted to use MongoDb. They had seen it used in lots of tutorials but I didn’t feel like a schema-less database would work out well with a brand new, undisciplined team. Seeing as Heroku also provides a free instance of Postgres I suggested we go with Postgres and an ORM with migrations so everyone could always restore an exact copy of the schema. This saved us a few times later.
I tried to save some time by setting the students up with a working starter that I mangled together from a bunch of other starter projects. The project had
You can see the starter at https://gitlab.com/darragh.oriordan/starter. I’ve since added typescript, heaps of tests and graphQL (Apollo).
We used GitLab over GitHub because at the time there was no CI/CD on GitHub and no free private repositories. Both of these are available on GitHub now. They hadn’t used a branching model before so I thought them a gitflow pattern. I made master a protected branch so they had to do pull requests to add code. Heroku would be deployed from master automatically.
I did some code reviews initially to set some standards and suggested they code review each others work after that. I don’t think this happened but it wasn’t a large project. If you wanted to enforce reviews then make review acceptance a requirement for merging.
I didn’t add any type checking system and I didn’t add any examples of automated testing. So the final product didn’t have any of this either. There were lots of regressions because of missing tests and basic type errors.
The students were going to use their university’s private cloud to host the application. They would be given a bare server to setup and use. Access to the server (even http) would only be on the internal university network. Given this limitation and the short timeframe I suggested Heroku would be better because…
Iterations worked well. The teams had a chunk of work to complete in a time they set themselves. Master and stage environment was always kept in a usable state. The sponsors had a product from about the third week that just gradually improved as the students merged in functionality. The sponsors spent a huge amount of time working on feedback for the students and that all got triaged by the students and fixed or abandoned.
The students used libraries for authentication (Auth0) and payment (Stripe). This worked really well for them. It saved weeks of work developing more bespoke solutions. There was still quite a bit of work writing email copy, sending emails, hooking auth up to back end, front end and the database. Payments was smooth.
We didn’t have a designer on the team so the site didn’t look professional. This was a huge problem in my opinion. I should have suggested that the first thing the sponsors do is to work with a designer. This would also have given the sponsors a nice paper based prototype to show to potential customers. It would have saved the what-ifs and maybe’s discussions throughout the project.
Mobile support was added AFTER the desktop layouts. This caused a lot of time to be spent reworking layouts. I should have suggested a mobile first approach. Many sites are seeing minimum 60-70% mobile usage these days so you need to have it. You might as well start with the constraints. A designer would probably have caught this earlier anyway. So hire a designer first:)
The students didn’t have experience debugging so I had to help out with that sometimes. It could be something you can go through with your brand new junior devs before they get stuck. Things like how to read the console logs and locate a line in a file in the source and how to set a break point. I also taught them the remove all code from a module and adding it back piece by piece until it breaks again method:)
The students completed all of the larger chunks of functionality agreed to at the start. There were some small compromises to get the project completed in time. There were some bugs in the final product too. I haven’t heard what kind of customer feedback there has been yet but with the design it might not have been great if customers expected a really polished experience.
However the students received some of the best marks in their class for the project and for me that’s a huge success.
Overall the same major issues showed up here as they would for any software project.
Are there any tips you would add for a senior developer or lead who is taking on a team of junior developers?
As a new developer do you remember anything that helped you out?
Let me know!
Hi! I'm Darragh ORiordan.
I live and work in Sydney, Australia enjoying the mountains and the ocean.
I build and support happy teams that create high quality software for the web.
Contact me on Twitter!