tools

Architecture of psbFinances

Vladimir psbFinances, software ,

Every time you start a new application, you ask yourself: what should I use to build it. Should you stick to what you know or use something new. I’ve made a few decisions about the architecture of psbFinances. For the last 9 years I’ve been working with node.js, React and MySql. I’ve built platforms for 6 startups with this stack. That’s what I used for psbFinances. But there was a couple of decisions I’ve made “inside” this stack.

Note that React is becoming less obvious choice for me these days, but that’s another topic.

TypeScript (TS)

I am big fan of Anders Hejlsberg. I was working with C# since he introduced its first beta. Even before that I’ve used his Borland Delhi. When he announced TypeScript in 2012 I was very interested. He gave many reasons why TypeScript was developed. Great tooling support (like IntelliSence, code completion) was one of them. Since then I was checking the growth of it and was asking myself whether I should use it for my projects. I’ve asked the same question many teams that I’ve lead: “should we go with pure JavaScript or with TypeScript”. Interesting situation. JavaScript developers wanted to have static typing. At the same time more C# developers were asking for dynamics.

9 years ago most of the JavaScript IDE didn’t have a good support for it. But the situation has changed a lot since then. I use WebStorm. It has a very good support for pure JavaScript development, especially in combination with JSDoc. Visual Studio Code has a great support for it too. For me using JSDoc makes code less verbose and cleaner compare to the type annotations in TS.

As for the static code analysis. Incorrect types add only a minor number of bugs that I discover in my and my teams code. Most of the bugs are in the logical flow. Type validation is also address as part of unit tests.

TypeScript allows to use the latest features of JavaScript. Browsers and node.js may not support these features yet. But you probably use Babel and that solves this issue.

That’s why I’ve decided against TypeScript for psbFinance. I don’t see enough benefits to use another “super” language on top of JavaScript.

Some developers say that “you can’t build large-scale application without TypeScript”. That’s not true. Large scale application can be built using any language. I’ve seen quite enough of them built with different languages. It’s not about language. It’s all about the skills and discipline of developers.

GraphQL

That was another tool I decided not to use. I use REST API. A debate of REST API vs GraphQL reminds me a lot about the discussion between backend developers and DBAs. DBA didn’t trust developers to be “gentle” with their databases. They insisted that database should be accessed via stored procedures only. That make sense. To some extend. “With great power there must also come great responsibility”. That debate was won by developers who now can write direct SQL statements or use some ORM helpers. I was never in the DBAs’ camp, even though I’ve done a lot of DBA work. For developers that power of accessing database with pure SQL is great. But some of them didn’t accept the responsibility. Many times I’ve seen lazy SQL code that degraded performance and introduced security issues.

That’s why it looks the same for me with GraphQL If you built multiple applications with REST API then you know how to address some challenges.

I am not saying that GraphQL is bad or that it should not be used. Far from that. What I am saying is that based on my experience and skills it doesn’t give me any significant benefits while introducing some complexity. It also means that the potential pool of developers who can contribute to psbFinances becomes smaller – not everybody know it.

Conclusion

TypeScript and GraphQL are great tools. They can be very useful in the right hands. But for me they don’t have enough benefits to use in this project. Check the code and you can see that it’s ok to live without them.

Stop using Slack

Vladimir Process , , ,

stop-sign-clipart.png

Confession – this is a flashy title to attract an attention. Slack is a great tool and you should use it. But, please, STOP abusing it.

Let me explain my point of view. It’s a great tool to have a conversation with your team members. But it should not be used to preserve the knowledge. What knowledge? Anything that related to your work like discussions about product features, roadmaps, decision points and so on that you may need to reference back in the future.

Let’s say you have to discuss a specific feature of your product. I assume that you already have it tracked in one of the applications like Trello or Asana. It’s so tempting to just jump into one of the Slack rooms and start the discussion there. But unless you have a room for each features, bug, task don’t do it. And, no, I don’t advocate to have a room for each working item you have to discuss. Instead of going to Slack, find this item in the tracking system that you use and discuss it there. Your discussion is the knowledge that you would like to preserve. It can be useful for you in a couple of months or for your teammates when they will need it later. One item – one place to store everything important about it. It makes much easier and faster to find information when you need it.

Have you ever came back from vacation to find your Slack room full of unread messages? No? Well, I guess you don’t use Slack then :). How can you get up to speed with any decisions that were made about a particular task? Search? Read all the messages in a particular room? But it has discussions about 10 other items, all “shuffled” and polluted with totally unrelated chatty messages. But if that discussion is kept with an item itself in the tracking system, then you will get what you need right away.

Are you a manager? Then you have to track all work items of your team. But you don’t have to track ALL of them right away. Some need your attention right away, but some – can wait. You know that there is a discussion going on, but you don’t care about it right now. You will deal with it later. But when the time will come, you want to get up to speed fast.

So, do use Slack. But keep your knowledge where it belongs – with your work items. A small effort to put the information where it really belongs will go a long way when you will need it.

Urgent vs delayed

Another disadvantage of Slack comparing to email + IM is no explicit sense of urgency. In most cases, when we receive email, we know that we can reply later (unless it’s stamped as urgent). But when somebody pings you via IM, it means that there is a need for an immediate reply. Well, this is how it is in most cases. And this is not very clear with Slack. Unless you read the message, you don’t know whether a response is expected right away or it can wait.

This is not a big deal, because it can be easily fixed with some tag or “stamp” of the post. Just agree with your team what it will be.

And remember, a tool only as good as the user.

Happy collaboration!