Cliff Berg
Aug 31, 2018 · 3 min read

A great honest account. Thanks for sharing. I would like to make some suggestions.

The single page app — you mention that one reason to choose it is “because everyone is doing it”. Indeed — as you suggest — that is a terrible reason, because IT is very fad-driven, and these fads often mire us in bad choices. The list of bad choices is long. See this article for a few. Single page web apps are yet another horrible trend, because Web technologies were not designed for that, and active Web technologies are the primary vector for malware. It used to be that one could block Javascript (e.g., using NoScript) and be safe, but with every site now using single page Web apps, that is becoming impractical.

On “the architect and the gardener” — this is an interesting way to look at it. It is similar to what one hears about in the sciences: “the theorist and the experimentalist”. It also explains why some people like TDD and some don’t (see these debates). On that topic, I would offer that an effective programmer needs some of both traits: that to just start coding without thinking through how something will work not a good approach: it wastes time, and leads to “spaghetti code”. On the other hand, it is very difficult to think of every detail ahead of time: indeed, that is one of my arguments against TDD — because I often find that when I implement something, I change my mind about the inputs and outputs, yet TDD compels one to write code that satisfies input and output requirements. My advice: design each complex algorithm before you code it, and design each key data/object structure; but then as you code, allow the design to evolve.

On having lots of tests, I have found that behavioral tests are invaluable; less so, unit tests. But this depends on the degree to which one chooses to design ahead of time, and it also depends on the language: if using Python, Ruby, or Javascript, I would always create comprehensive unit tests; but if using Go, Java, Kotlin, or any other typesafe language, one does not need a refactoring safety net, since the language itself provides it. Thus, IMO, comprehensive unit tests are a kind of “tax” that one has to pay if using non-typesafe languages. I know the TDD proponents will disagree with that, and we are back to the division between the “architects and gardeners”. That’s okay: people can work differently, think differently.

This brings me to the stack choice. For a project that has a short lifetime and a small cohesive team, use a high productivity language (Python, etc.); but for a project that will be around for awhile and touched by many people over time, use a highly maintainable language (e.g., Java, Kotlin, Scala — not Go: Go has horrible maintainability characteristics: just Google “Go gotchas” and you will find some of them).

On the issue of being blocked by company servers, compiling third party components locally is probably a violation of corporate rules, and you could introduce security vulnerabilities by doing so. A better approach is to get the third party components added to the corporate artifact repository. However, what to do in the meantime? Yes, compile them locally if you have to — kudos for taking the time to do that — and test them locally — but only locally.

An interesting article. Thanks again for sharing!

    Cliff Berg

    Written by

    Author and IT consultant