What’s missing from the Agile process?

Architecture.

I know. For agile folks, that can be a dirty word. Yet XBOX Live was developed entirely using Scrum with well over 100 developers, in one-week sprints, with continuous integration, without breaking into silos.

And the resulting platform is 100 times more secure than the monolithic PlayStation online platform.

How was it done? Architecture.

Software architecture creates an API that reflects underlying information objects, captures the needs of scalability for different classes of services, and allows the front end to vary completely independently of the back end.

Software architecture allows the partitioning of functionality without losing system cohesiveness and without creating silos in your team structure.

Good architecture is the missing ingredient with most agile teams and without it, you can never be truly agile.

Hire some decent architects.

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.

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.

Is Web Development Dead?

Personally, I’d give it about 5 to 7 more years, maximum 10. I’d even kill off web design alongside it. I am talking about website development, specifically where the developer is concentrating on writing code that manifests directly on a website, rendering HTML and Javascript.

Web development is a broad term though because API development that manifests as JSON data across HTTP requests could also be considered web development.

When web design was a top role for designers, about 12-15 years ago, it was because design demands were rooted in print design. This was before mobile phones were a viable browsing tool, so you could bank on having consistent screen sizes. This was also at the time when broadband for the home was common enough that the average person could view a complex website that was so abundant with a skeuomorphic design that the bandwidth requirements were high, but the quality was high as well. As a result of complex design, web development was also a dominant role, because it was a lot of work to develop alongside that complexity of the design.

But as mobile device usage has grown, and the separation of concerns from websites being king, to instead a combination of websites, apps, and other services, the website’s need for being gloriously designed decreased. Given that we continue to have an increase in device variety, this trend is not going to reverse itself. A simple, clean design is best suited to auto-adapt to the variety of screen sizes and types that will be available for decades: visually, this is all the way from a wristwatch to a billboard.

Based on that, the majority of website development has already shifted to more data-centric work, above design-centric. If I’m viewing website content on my computer, the design might matter to me. But when I switch to my phone, design (at least, heavy graphical design) is only going to get in my way. The design components that will matter on my phone are color, typography, readability, etc. There will still be a need for designers, but far less than what we needed a decade ago, and certainly less than we need now. Designers will need to branch into more cross-device creative direction than simply “website design.”

And developers are already heading that way, by avoiding design and focusing on API development, which is critical for driving website content while also driving the two other most important technologies needed right now:

  • Apps, which are currently manifesting primarily as mobile apps, but which also include voice-activated apps, and VR apps (through independent devices like what Google tried with Glass), and
  • Integration, which is the data-sharing aspect of API development that allows the data from one app to be integrated with the service of another app to provide suite-like features across disparate systems.

When a design is needed, most of the existing frameworks can already handle 95% of the design needs a company has. What we’ll be lacking though, unless the trend changes, is qualified business experts who can properly capture web application needs from business owners to develop solutions that fit company requirements. The demand will be on making custom applications at a fraction of the cost of what it used to be. The more APIs there are out there to perform the functions we need, with integration at their core, the more a website is just going to be a clean merger of technologies from a variety of sources, and design is going to remain minimal, because that same content needs to adapt to varying phone sizes, a watch, a lens over my face, an audio interface reading back to me, VR projections from a headset, and so forth.

So web design and development as we know it today, is going to be mostly gone within a decade. API development, app development (in many forms) and systems integration will be the primary focus.