What are the pros and cons of Sitecore over other content management systems?

Sitecore is a powerful .NET framework and is almost entirely customizable down to its own user interface. It leverages much of what makes .NET great like the role-based security. It allows for a modular templated architecture based on data templates that if done correctly provides a developer with a code-less, do more approach in which content types inherit values and parameters and can be nested to fulfill complex business rules (hierarchical or otherwise) and re-used everywhere. Its API allows for almost complete control of the rendering pipeline, with database-driven content completely divorced from presentation allowing for customizable rendering rules like persona-based personalization, custom device delivery, multi-site (reusable architecture), multi-language and A/B and multivariate testing. Sitecore requires a lot of configuration however both to function as desired and in order to be easy to use. And therein lies the rub, by being so open, so configurable, many developers that cut corners also wreck the content manager’s user experience and make the whole solution difficult to manage, upgrade and deploy.

With its great flexibility for the developer then, comes with great responsibility. You can start with a great platform and get a lousy implementation. Developers who fail to treat the Sitecore platform and their website as an application and apply ALM best practices can easily create an undocumented mess of code and architecture. If programmatic rules are used rigidly without overrides, a content manager can feel hamstrung especially if tiny tweaks involve development and deployment (isn’t that the point of a CMS, to alleviate the need for development). HTML and CSS can be used in-line and hardcoded to particular front-end frameworks to a developer’s peril. However, if you build on a solid foundation Sitecore can act as the integration framework for all your web services, back-end processes, and customer analytics (via the MongoDB platform or xDB, experience database). A developer can build custom e-commerce experience, integrate with CRM, ERP, and manage content for non-sitecore sites, mobile apps and kiosks. If I were a company banking on providing a great user experience for my customers, partners and power users, I’d invest in Sitecore, but I’d also invest in a great technology provider to implement it.

The future of React Native?

The increasing demand for faster app development might be the reason why cross-platform applications are on the rise. In fact, React Native is already perceived as a viable solution to create quality software and its use expected to grow in the coming years. 

Yet, not everyone agrees that it’s the way forward for mobile app development. And rightly so – there are still some technical drawbacks that are holding React Native back, not to mention that it generally offers slower apps when comparing them with native solutions.

Despite the constant advancement of React Native, it does not provide ready-to-use modules that give access to iOS or Android APIs. This forces developers to create so-called Native Modules themselves or develop “bridges” using Java/Kotlin (Android) or Swift/Objective-C (iOS) and severely increases software development time.

Developers bring up one more problem with React Native technology — software debugging. It is much harder when using RN. It comes down to faster development but longer problem-solving which results in less accurate cost estimation (especially in case of Android).

The framework might look strong on paper, but many well-known apps (such as Airbnb or Udacity) has actually switched back to native development. Therefore, even though React Native is definitely a trending topic at the moment, only time will tell if it has the power to outshine native technologies.

How popular are Node.js and Python for web development?

According to this report not long ago, Node.js is used on 0.6% of websites, Python is used by 1.1% of websites:

PHP vs. Python usage statistics, December 2018

With PHP at 78% as the dominate backend language.

Node.js can probably creep up towards 1%, but I’m not really expecting it to.

I think Node.js has probably peaked, maybe if TypeScript gets a lift, it’ll take Node.js with it, but to beat Python, Node.js needs to almost double its market share, and I just don’t see that happening.

0.6% doesn’t sound like a lot, but remember it is 0.6% of all websites.

All things considered, I’d say they are already similarly popular.

What will be the dominant front-end technology in 5 years time?

In short, you might as well play roulette and bet on black, because nobody can answer this question with fact. We can only present hypotheses.

The world of web development, especially front-end development, evolves about as quickly as the physical tech industry does, and there is no way we can predict what Samsung, Apple, Nokia, and the other’s will churn out in even the next two years. Much less five.

Let’s look at a bit of JavaScript history.

Build Tools (2014 – 2018)

  • Three years ago, Grunt was the dominant build tool.
  • Two years ago, Gulp rose up and stole the throne.
  • One year ago, was Webpack’s claim to fame.
  • Somewhere in there, Browserify fought a good fight.
  • At one point, plain npm scripts became a fad.
  • When I wasn’t looking, Rollup rolled out.
  • Along the way, I built Owlister. (It is junk. Don’t look.)
  • Now, Webpack dominates, but tomorrow is unpredictable.

Transpilers (2009 – 2018)

  • Eight years ago, Coffeescript became Earth’s favorite abstraction.
  • Six years ago, Dart arrived like a drunken monkey on weed.
  • Five years ago, TypeScript was born, bringing type safety to JavaScript.
  • Three years ago, Babel arrived to let us use future JavaScript today.
  • Two years ago, Elm became a buzzword. (Nearly irrelevant, but not quite.)
  • Now, TypeScript and Babel rule. Seemingly invincible? Time will tell…

Frameworks (2010 – 2018)

  • Seven years agojQuery was the most suggested JS “framework”.
  • Six years ago, Backbone and Knockout were widely adopted.
  • Five years ago, Angular and Ember took the stage.
  • Four year ago Meteor stormed the gates and built a following.
  • Three years ago, React took its first breath. The prophecy…
  • Two years ago, Polymer and Vue made names for themselves.
  • One year ago, [Angular 2 and Vue 2] released, [bombing and succeeding].
  • Six months agopeople quit caring that “React is not a framework.” Don’t.
  • Now, Angular 4 has arrived, React dominates, and Vue is a super-power.

*These numbers are not exact, but even the absolute correct time-frames would reveal an identical pattern of “king of the hill”. Don’t grill me.

But wait, there’s more!

In the midst of the frameworks timeline, there have also been countless other contenders take a shot at stardom. Aurelia, Riot, Spine, Dojo, Deku, Inferno, Mithrill, Stapes, Svelte, etc. Any one of these lovely ladies could become the new hotness in a matter of weeks. We just can’t tell.

If I were to revisit this answer in five years, I’d most definitely be adding weird framework titles to my timelines above, as even the power-houses of today will not last forever. These tools will probably be such that I have never even heard of at this point in time.

Behold, WebAssembly.

WASM is… difficult to explain. Simply put, WASM allows developers to compile most any language into performant, browser agnostic byte code. What this means is that the front-end community has the opportunity to detonate yet again with a landslide of developers from all walks of life developing for the browser.

JavaScript has done its job well, but as the world progresses it will be replaced. That time could very well be within the next five years. The murderer could be WASM or it could be a new browser that takes a majority of the market share that allows developers to write their applications in Haskel. Improbable, yes. Impossible, no.

The Safe Bet.

As it stands, our best guess is that JavaScript will still dominate the browser in five years. That said, your best bet would be to acquire a slew of developers who are tool/framework agnostic by means of deep JavaScript understanding. Don’t allow yourself to be contracted to a specific tool. I guarantee you that Angular, React, Vue, Backbone, Aurelia… none of these guys will reign in five years.

Those who become proficient with languages and have a firm understanding of design patterns and architecture will have no problem adapting to future tools and are, in essence, future-proof.

Should you learn Docker?

Maybe yes. Maybe no.

If you ever write server/back-end software, it should be a requirement today that you know Docker.

If you create applications, it’s good to know Docker so you can create a standardized build environment. You never really want your application release builds to come off a developer system, and it’s even better if the standard build system can be defined in software.

If you want to run a specific version of a database on your development system, then Docker can do that pretty trivially as well.

If you have problems with version conflicts between various installed environments (Python 2 vs 3, various gcc[lib] versions, other tools installed globally, etc.) then Docker can be useful to set up the perfect environment to run a picky tool, and once it’s working you can share that environment with a coworker and know that it will just work.

Docker is a tool. You should learn it if it will help you do your job. The above examples are not exhaustive. Any time that it would be good to have a standardized environment on your development system, for testing or sharing or running specific software, Docker would be useful.

But if you never need it for the above reasons or otherwise, then no, you don’t need to learn it. It wouldn’t hurt to learn it just in case. But there’s no “should”. It’s really, really not hard to learn, though. At least if you understand the command line.

Why do backend developers have more confidence in their profession than frontend developers?

Because 99% of the time when someone identifies as a front-end developer they are saying that they have not been a developer for very long.

Think of it this way. On the web, Ajax was “invented” in 2004 (actually Outlook was doing it in 1999 but shh…we can’t give Microsoft any credit). It did not become a central part of most web developers’ lives till 2008/2009 or so. Even then, Javascript was avoided by many until frameworks started coming out in the early 2010s.

So what were people who were already established developers pre-2010 doing? Working largely on the back-end. So now that they do a lot of front-end work too, they face the choice, do they brand themselves as a “front-end” or a “full-stack” developer? I certainly choose the latter.

Which leaves most people who embrace the “front-end” moniker as people who have been coding professionally for less than six years. So yeah…they’re less sure of themselves.

For the record, I use the “front-end” and “back-end” terms above in the manner I see them used more often, with “back-end” meaning server-based languages, databases, etc; and “front-end” meaning HTML, CSS, and Javascript. Personally, I dislike those definitions and prefer “back-end developer” to indicate how good someone is at understanding architecture, performance, databases, and security; and “front-end developer” to indicate to what degree someone thinks about human-computer interaction, responsiveness, UI optimization and reusability, browsers, responsiveness, and accessibility. When you formulate definitions this way you start seeing these as two largely orthogonal dimensions of a square, rather than anything mutually exclusive.

Disclaimer: I use 99% rhetorically. It certainly is an overwhelming majority but I haven’t done any data gathering on the subject. That being said, I certainly don’t claim that front-end development is easy. There’s a huge amount of churn. There aren’t many other areas of development where people have to actually stay on top of language specs. 

Why React Dev’s Like to Hate Vue.js

After having worked on React development on medium/large scale apps, I have to admit that VueJS is like a breath of fresh air.

In my opinion, most developers are having as I call it the “Simplicity (Un)reasoning” bias, which means: if it is simple to learn, simple to use then it is for simple projects. Crazy right?

Meanwhile, the arguments in favor of React or Angular 2+ are dubious as well.

Angular is for large teams because it enforces you to write code in a typed way because of TypeScript. Yes but React and Vue support TypeScript or Flow not to mention that Vue’s lifecycle events are more clear cut than React’s.

Vue has only one person writing code. Not anymore.

Vue is for simple projects. Maybe you should read how Adobe is using it these days.

I am not writing this specifically for Vue but believe me that this simplicity can be found in other libraries as well e.g. RiotJS, StimulusJS etc.

Unfortunately, React and Angular have excellent marketing strategies, which plays a major role since they are trying to sell longevity instead of code happiness. By code happiness I mean the factor which make your developers happy to write code they understand and are proud they wrote it. With React and Angular I am not that happy, especially with React.

With Vue the selection was being made from a pool of 10+ team leaders because it just works as it should out of the box. Their vue-cli is also in the same league angular-cli is, but the difference is were angular could not operate very efficiently without, Vue could work without it with no problem.

Finally, I have to point out that lately among the majority Front-End developers, there is this strange notion that if your code is easy to understand, not very complicated and not using the latest ESxxx you are doing something wrong. If you look at Angular you have to learn RxJS, TypeScript etc. and even if you are not satisfied with this selection few will admit it. We have to get rid of the herd mentality and marketing strategy of 2–3 large companies and exercise common sense and independent spirit.

How do you know if you wrote readable and maintainable code?

Dissecting the question, we have two operative terms here: “readable” and “maintainable.”

Let’s talk about what these mean.

“Readable” would describe code that is understood without much inspection or explanation by another developer. You have to choose what parameters you want to describe the “other developer” to know what would be readable to them.

Some things are somewhat universal and limited by human factors. For example, few people can follow poorly named variables. (There’s your first heuristic – are there clear names for variables, classes, methods, and other references?)

Other things are a bit more nuanced. For example, if the developer uses the language you are writing in on a regular basis.

Or, is the developer familiar with the domain the project operates within? How experienced are they as a developer? Do they have a particular background that might make the code more or less readable to them?

But what if you don’t know who the other developer is?

This is why we develop standards, patterns, and best practices. For example, JavaScript code tends to use camelCase, so writing your code with camelCase provides a sense of fluidity (which plays into readability). Knowing the common patterns and style that the language typically uses is important. (As an additional note, your organization may have your own style defined; follow it.)

Some simple, practical heuristics to follow:

  • Use descriptive variable names. Longer variables are more easily read.
  • Use whitespace! Compilers and minifiers mean that whitespace is free. Take advantage of this.
  • Practice finding a balance between abstraction and practicality. You do not need 10 layers of redirection for simple tasks; start with the simplest approach and abstract during a refactoring process.
  • “Make it work, make it right, make it fast.” In that order. This will immensely help the readability of your code, because you start first from comprehension, and then move towards performance. This establishes your pattern and semantics up front, and you are more likely to maintain good semantics this way.
  • Know your audience. If your audience isn’t used to inline lambda calculations, skip it. Even if you believe it is the “best way” to solve the problem, there are other equally good ways most likely available.
  • Follow well-established refactoring and OO patterns. Seriously. These things have been tried and tested, and they work. Look here for a good description of many of these patterns: sourcemaking.com/design_patterns
  • Don’t follow rules blindly. Take some time away from the code and revisit it – what sticks out as weird? What sticks out as confusing? When does your brain feel tired?
  • Readable code isn’t always maintainable, and vice versa. Maintainable code is established by following good practices and principles.
  • Tests are HUGELY important to codebase maintenance. Having good test coverage keeps you from having to load all of the codebases into your working memory (in your head), and reduces errors. (Note: tests won’t eliminate errors altogether; they are there to help you, not to make you obsolete.)

All-in-all, coding is a human process. Follow Hemingway’s advice when writing code. Simpler is typically better.

Top 8 Signs Your Writing Bad Unit Tests

If you have been developing software for a long time, then you can easily relate to the importance of unit testing.  Experts say that most bugs can be captured in the unit testing phase itself, which eventually gets passed on to quality teams.  Here is a list of my top 8 signs your writing bad unit tests.

1) Test passes but not testing the actual feature

Believe me, I have seen test cases in some projects that appear to be doing lots of work in the code but in reality, they were doing nothing. For example – a test that’s sending requests to the server and no matter what the server responds with, the test was passing.

Beware of these such test cases taking place in your code repository by doing strict code reviews. Once they make their way in your code base they will become a liability on you to carry them, build them, and running them every time but without adding any value.

2) Testing irrelevant things

I have seen developers checking multiple irrelevant things so that the code passes with doing [something], well not necessarily the correct thing. The best approach is to follow the single responsibility principle, which says, one unit test case should test only one thing and that’s all.

3) Testing multiple things in assertions

In the previous sign, the test was testing irrelevant things. For this sign the unit-test is testing the correct items,  however, there are too many items in one test case. This again is a violation of the single responsibility principle.

Well, please note that I am not encouraging the use of a single assertion per test case. To test a single entity, you might need to use multiple assertions, do it as needed.

For example, one API which takes some parameters in a POST body then creates the Employee object and return it in response. This Employee object can have multiple fields like first name, last name, address etc. Writing a test case to validate only first-name, then another for last-name and another for the address is duplicity of code, without any value. Don’t do it!

Instead, write a single positive test case for creating the Employee object and validate all of the fields in that one unit test. Negative test cases should be written separately doing only one thing and one assertion in this case. e.g. One test case for blank first name, one test case for invalid first name and so on. All such negative test cases can be validate using a single assertion which expect an exception in response.

4) Test accessing the testee using reflexion

This one is real bad. Trying to change the testee to suit ones need.  The test will blow up when the testee may refactor some of the code.  Do not use this or allow to be used either.

5) Tests swalloing exceptions

I have seen my fair share of such test cases. They silently swallow the exception in little catch block at the end of the test case. And worse is that they do not raise a failed alarm. Exceptions are signals that your applications are trying to communicate that something bad has happened and you must investigate it. You should not allow your test cases to ignore these signals.

Whenever you see an unexpected exception, fail the test case without failure.

6) Test which depends on some excessive setup

I do not like test cases that require a number of things to happen before they start testing the actual thing. Such a scenario could be an application which facilitates online meetings. Now to test whether a user of a particular type, can join the meeting, below are the steps test is performing:

  • Create the User
  • Set user permissions
  • Create the meeting
  • Set meeting properties
  • Publish meeting joining information
  • [Test] User join the meeting
  • Pass/Fail

Now in the above scenario, there are 5 complex steps which must be setup before actual logic is verified. For me, this is not a good test case.

A correct test system will have an existing user present in the system for this activity, at least. This will reduce at least two steps in the test case. If appropriate, you could have a few already created meetings to make this test case really focused.

Another way to make it correct is by using mock objects. They are there for this very purpose.

7) Test compatible to only developer machine

This is not widely seen but sometimes visible when written by freshers. They use system dependent file paths, environment variables or properties in place of using common properties/paths.

8) Tests filling log files

This never seems to be an issue until you need to perform a deep debug then make life hell for debugger who is trying to find something hidden in those log files bloated with wasteful messages.

Tests are not for debugging the application, so do not put debug statements in your logs. A single log statement for Pass or Fail is enough. Believe me.


These are my thoughts based on my experiences. I do not expect you to agree with me on all of the above points or you might have some other opinion which is perfectly cool too.

If PHP “does’t scale” why use it?

I would summarize:

The main issue is that server time is cheaper than developer time.

A scripted language like PHP (or Ruby, etc.) takes about half as much time to program as bytecode or compiled language like Java (or C, C++, etc.).

So if you have a team of 10 developers each paid $100K, then you are paying out $1M in salaries. If you replace Python with Java, now you need to hire 10 more developers and pay out another $1M. In exchange for what, saving $50K of server time? Obviously, that’s not worth it!

If you already know PHP then go with it. Especially if you want to get to market as soon as possible to have an early mover advantage. Experienced PHP developers know that they could find out where to optimize once their site is in production and its features had been decided on.

This is a good example for other startups. The combination of rapid development time and flexibility on the front end and speedy service time on the backend is a good example to imitate.

As a professional PHP engineer:

The stigma that PHP applications don’t scale well comes from the fact that many inexperienced programmers choose PHP for their web applications. This is because PHP is an easy language to learn, integrates extremely well with Apache, and is supported on nearly every host in the world.

Inexperienced programmers will often use bad practices when writing code. Given enough of these bad practices littered throughout the web, written in the inexperienced programmer’s favorite language, it’s easy to see why some people are averse to PHP.

There’s also, probably, a “holier-than-thou” attitude that some programmers have toward PHP (again, because of its simplicity).

PHP scales just as well as any other language when page caching and best practices are taken into account. There are plenty of well-used PHP projects to prove it.