Each week I write a blog post which describes what I learned that week. I write these blog posts for two reasons.
First, I want to keep track of my personal development and writing regular blog posts is a great way to do it.
Second, I want to share my findings with you. I hope that you can use some of them in your daily work.
Let’s get started and find out what I learned in week 32.
What I Learned in Week 32
First, It is not a good idea to have separate frontend and backend developers. This situation has two problems:
- If you have problem in your backend and all backend developers are nowhere to be found, you are screwed (and wise versa). Also, even if the frontend developers are capable of writing backend code, they cannot be productive right away because they are not familiar with it. If you need to fix that problem fast, you are out of luck.
- If the backend and frontend code is written by different developers, you need to specify the API provided by the backend before any code is written. Also, you have to take extra measures to ensure that the frontend and backend developers are not making "incompatible" assumptions. If you are in hurry, this might not be a viable option.
I am not saying that specialization is a bad thing. However, I think that all developers should write both frontend and backend code.
Second, All Hipster tools don't suck. Actually some of them are pretty awesome. For example, if you are building a single page web application, you can build a pretty good dependency management and build automation system by using NPM, Bower, and Grunt. I admit that I don’t have a lot of experience from this but my first experiences were very positive.
Third, I have always thought that storing hierarchical data to a relational database means that you have to create a hierarchical table structure. Last week one of my colleagues told me that he decided to describe the hierarchy as a JSON document and store that document to the used database.
I was very surprised (and a bit ashamed) to hear that because this idea never crossed my mind. However, when I think about it, it makes perfect sense. This solution is simple and it does not suffer from performance problems associated with the "traditional" solution. This reminded me how easy it is to get stuck in old habits. Sometimes it is definitely better to think out of the box.
Fourth, Using JSON instead of XML does not mean that you get better performance.
Fifth, I have been looking for a good code colorer plugin for WordPress. The SyntaxHighter Evolved is probably the best existing WordPress plugin for this purpose.
Anyway, yesterday I received email from Mark Lishman. He is working on a startup which provides an easy way to create online tutorials. The cool thing about this product is that you can create interactive tutorials and highlight parts of your source code when the viewer of your tutorial clicks a special link. The product is still a bit rough but the idea is very interesting, and it helped me to see online tutorials in a new light.
What Did You Learn This Week?
Share your learning experiences or other comments on the comment section.
I agree with you that "all developers should write both frontend and backend code". My question is which part to start first? Sometimes I feel it is better to provide frontend UI first to clients, then design and code backend domain model (database model as well) later. What is your experience?
That is good question.
If you are implementing a single page web application, it is indeed possible to create a working prototype without any backend code. This approach has the following benefits:
The "downsides" of this approach are:
I guess the answer to your question is: "It depends".
I like the approach you suggested, and I would call it "Analysis and Design Stage" first, focusing on front-end UI design. It is not a deign on the paper, but a working prototype, because a working prototype can reveal lots of details of the application, so after finishing UI prototype for all use cases, clients and designers can pretty much understand the business domain model and process model very well. Then "Implementation Stage" second, to design and implement back-end code with physical database model, and integrate front-end code together. Of course during implementation stage the design may need more updates, because more details are discovered.
IMO, "continuous delivery" cannot work very well, because both clients and designers/developers need time to understand the business and the application, so better save the time at the design stage.
I think that I read about this approach from a book called Inspired: How To Create Products Customers Love. It did make a lot of sense but since I am mostly involved with agile projects, I usually use this approach for only one feature (the one which is under work at the moment).
Also, I don't always do a fully functional prototype. If the feature is pretty simple, I usually just implement it and ask for feedback. This way I can get minimize the time spend on communication because the product owners are not necessarily working in the same office than we are.
A word of warning though, you probably should not do this if you are not familiar with the domain logic and are not sure what problem the feature is going to solve.
Continuous delivery sounds like an interesting concept if you (and the customer) are willing to accept the fact that every feature will not be a home run. However, I have not been in a project which uses it.