If you have been watching the news of late and let’s be honest, who hasn’t given we are a part of an unprecedented global pandemic? Then you would have heard of the announcement of a contact tracing application you install on your phone which notifies you and others if you’ve been in contact with anyone who tests positive for COVID-19.

On the surface, every day Australians will hear the government say, “If everyone installs this, we can ease restrictions faster and flatten the curve by being able to control the spread” – but for those in tech like myself who are critical of the government’s ability to produce an app that won’t be a privacy nightmare, things are a little more convoluted.

While I agree that unprecedented times call for unprecedented measures, an application that involves any level of tracing and data collection needs to be handled in a delicate manner. The app is based off of the Singaporean application TraceTogether which uses proximity (distance) to other phones and Bluetooth.

When you get close to someone else, the apps swap anonymised encryption keys which are stored on the phone and deleted after 21 days. After some initial confusion as to whether or not the app would be mandatory (not helped in part by authoritarian sounding remarks from Chief Deputy Medical Officer Paul Kelly), Scott Morrison cleared things up in a Tweet.

Allegedly, Morrison and others are pushing for an application which would have greater privacy protections than the Singapore application. However, we should be wary until we see the final application. Even some federal government MP’s have come out and said they won’t install it.

Installing government-sanctioned surveillance software on my phone would require some serious guarantees from the government before I would consider doing such a thing.

1. A hard sunset date that cannot be extended. The government needs to provide a date in which the servers are wiped and the apps are rendered non-functional that they cannot freely extend.
   
2. Guarantees that the scope of the tracking will not be expanded beyond its initial purpose. We all saw what happened with the site-blocking list legislation initially intended to block child pornography and other illegal sites, then amended to make it easier for the entertainment industry to block torrent sites.
   
3. The code made completely open-source and freely accessible to not only security researchers but to the general public like myself who will want to dig into the code and see for myself what it is doing. Furthermore, the source code for the server as well to ensure that data isn’t being sent to an insecure honeypot.
   
4. Protections put in place preventing who has access to the data sent to government servers. We all saw what happened with the mandatory data retention laws and reports of violations of people obtaining access to information which they shouldn’t have been able to.

We will see what happens when the app is released, but I implore others to be sceptical of a government created tracking application, even if on the surface the intentions seem to be good. We have seen time and time again the government passing legislation and reducing freedoms under false pretenses and then subsequently amending legislations to expand the scope.

When it comes to JavaScript frameworks, few can lay claim to the longevity of Ember which just turned eight years old. To give readers some perspective, Ember is about as old as AngularJS (the first version of Angular), older than React, older than Vue and many other options out there. It harks back to the days when IE6 was still a browser many of us had to support.

To the surprise of some who abandoned Ember (and JavaScript frameworks in general) years ago, Ember just released a large update which changes and improves Ember in many facets. For years, Ember has been trailing behind other frameworks and libraries. Even though updates were still being made, Ember has always felt like a relic of Web yesteryear.

Despite trailing behind newer, faster and smaller options, Ember has enjoyed success at numerous companies including LinkedIn and Intercom. Nobody can argue that Ember isn’t used or that it is even dying, it’s just not that popular any more. It’s hard to deny that React has eaten front-end development.

With Ember Octane, many facets of Ember have been improved, Ember applications are still overly verbose and the templating syntax which uses Handlebars feels outdated.

In Octane, some of the changes actually resemble that of Aurelia dating back to 2015. Previously, view-models and templates were located in separate directories. The old approach looked like this:

app/
  components/
    my-component.js
  templates/
    components/
      my-component.hbs

In Ember Octane, this now resembles that of frameworks like Angular or in my opinion as mentioned, more closely to Aurelia:

app/
  components/
    my-component.js
    my-component.hbs

As you can see, the view-model and template are in the same directory now. Likewise, Ember Octane introduces a new decorator for computed properties called @tracked which is reminiscent of Aurelia’s @computedFrom decorator. A similar concept further cemented by the introduction of a decorator called @computed in Ember Octane.

I think Ember Octane is a step in the right direction. Some parts feel inspired by React and other parts feel inspired by Aurelia. Still, looking at Ember, it feels overly complicated and like it is still playing catchup with Aurelia from 2016 or really, every other established framework using modern Javascript syntax.

For me personally, there is nothing in Ember Octane that is exciting or innovative enough that it would suddenly win back developers who left Ember or have eschewed it for other options such as React and Vue. Still, it is great to see the project is maintained and this is all a positive step in the right direction.

I don’t want people to misconstrue this post as a beat-up of Ember with a hidden agenda to promote another framework. I think the more frameworks and libraries there are, the better. But when you’re competing with the big daddy React or up and coming superstar Svelte, you have to bring something substantial to the table and really, Ember doesn’t feel that different when you dig beneath the surface.

People once thought the banking industry was too big to fail, some seriously big financial institutions ultimately proved that wrong during the Global Financial Crisis of 2008/2009 which saw many seemingly unsinkable companies go out of businesses.

Early 2019, after two deadly crashes of the allegedly bigger and better 737 MAX, the plane was grounded by countries around the world as people scrambled to find answers for what happened. After numerous investigations, the culprit turned out to be MCAS also known by its non-abbreviated mouthful of a name Maneuvering Characteristics Augmentation System.

The issue with the 737 MAX was engineers were tasked with fitting larger and heavier engines under the wing of the plane. The engines had to be moved slightly higher and moved forward, which ultimately caused a dynamically unstable airframe. The solution was MCAS which used a single sensor to determine if the nose of the plane should be pushed down (as a safety measure).

While the 737 MAX continues to collect dust in parking lots and warehouses, Boeing is bleeding money. Just recently, they announced they’re halting production of the MAX (which will only slow, not stop the money bleeding). The solution Boeing has come up with involves comparing data from two AOA (Angle of Attack) sensors and comparing the difference if both sensors cannot agree, the MCAS does not override the plane as detailed here.

The company was hoping to have the 737 MAX recertified by the end of 2019, but this has been pushed back to 2020. Understandably, this entire situation does not just reflect badly on Boeing, but also the FAA who allowed this to happen in the first place.

Too Big, Too Influential

For any other company, two tragedies and a grounding going on for almost a year would be enough to plunge them into bankruptcy and put them out of business. For Boeing, their stock has been affected a bit, but they’re still okay.

Boeing is a company that has been around for over one-hundred years. When it comes to the aerospace industry, you don’t get any bigger than Boeing. Since the ’90s, the presidential fleet of planes consists of two Boeing VC-25’s which are military versions of the workhorse Boeing 747.

In terms of employment size, Boeing is one of the largest American employers. They employ over 150,000 people, many of those work in the US. If Boeing were to go out of business, the US economy would be affected. Not to mention the supply chain Boeing has created rivals even that of a company like Amazon and its supply chain.

Fly on any major airline in most parts of the world and chances are you are flying on a Boeing built plane, most likely a variant of the Boeing 747.

To get an understanding of just how influential Boeing is and its importance to the US, look no further than the fact the CEO of Boeing (Dennis Muilenburg) still has his job (CEO’s have been fired or forced to step down over less) and has not been summoned to Washington to be grilled before the senate over the tragedies and mismanagement of the 737 MAX.

You don’t get any more influential than not being held accountable or even being questioned on why two tragedies in such a short space of time even took place (the 737 MAX tragedies were unprecedented). When the banking industry collapsed, bankers were dragged before congress to be held accountable.

Still Waters Run Deep, Boeing Runs Deeper

When you and I think of Boeing, we think of a company that makes passenger planes. However, Boeing has its fingers in many pies, it’s producing the pies, it’s eating them, it owns the pie factory, it owns the supply chain that is shipping the pies to stores and restaurants.

Not many people realise Boeing also props up other companies and industries. Their subcontracts with General Electric (GE) and United Technologies and Spirit Aerosystems are some of the biggest. You best believe Boeing is adding a few zeroes to the books of those contractors.

Boeing is entrenched in both civilian and military sectors. They sell planes, rockets, satellites, telecommunications equipment and even missiles. They are the largest exporter by dollar value in the US. As far as size is concerned, Boeing is a juggernaut, a core pillar of the aerospace industry.

They are already saying that the halting of the 737 MAX could affect the US’s GDP in 2020. Not many companies can lay claim to being so big they contribute to the overall GDP of a country.

Even if Boeing were to get into serious financial trouble, the US government would not even hesitate to bail them out. It would probably be considered a national security risk if Boeing were to go under given their influence and reach in the defence sector alone. Quite simply, Boeing could sustain many more missteps and accidents before it really affected them and forced the government to step in.

The hype surrounding Svelte right now is inescapable. Every blog post comment section, the article comment section on Dev.to or Twitter thread/hot take seems to solicit a response about Svelte.

If you are not familiar, Svelte is a Javascript library which leverages a compiler to turn your Svelte code into plain old Javascript and HTML. You write your applications inside of .svelte files and they get compiled to something that has no runtime.

This puts Svelte into a similar league alongside Elm, Imba and a few others, not directly in line with React or Vue. However, being compared to React or Vue seems to be unavoidable in 2019 and will continue to be the case into 2020 and beyond.

In many ways, Svelte is an indirect competitor to the likes of React and Vue, both options which like to tout their small bundle and application sizes. On that front, they can’t compete with Svelte.

Where Svelte differs from other options like React and Vue is that it does not have a virtual DOM, no runtime or anything else non-standard after it is built. Syntactically, your applications end up looking like old-school AngularJS and Vue syntax and a little sprinkling of React’s JSX syntax thrown in:

<button on:click={handleClick}>

A lot of the examples you will see for Svelte highlighting its simplicity are not indicative of real-world applications. This rings true for many framework and library examples, showing as little code as possible. You don’t want to scare away users.

Where things start to look less HTML and Javascript-y is things like loops or conditional each statements. The following is an example of iterating over an array of users.

<ul>
    {#each users as user}
    <li>{user.id}: {user.name}</li>
    {/each}
</ul>

If you have ever worked with Handlebars templating in Javascript before, then this syntax will take you back to the mid-2000s right away. This is one example of a few other uses which also resemble Handlebars in Svelte.

Syntax aside, it is by no means a large criticism of Svelte. Every framework and library deals with looping over collections differently, except maybe for React and JSX which the community mostly uses a map to loop over items in collections.

In React’s JSX you will find the following approach is the most widely used:

    <ul>
      {users.map((user, index) => {
        return <li key={index}>{user.name}</li>
      })}
    </ul>

I actually would have loved to see Svelte adopt Aurelia’s approach to syntax instead of going down the path of Vue-like syntax and throwing in that Handlebars syntax.

In Svelte binding the value of a text input looks like this:

<input bind:value={name} placeholder="enter your name">

And in Aurelia, binding a text input value looks like this:

<input value.bind="name" placeholder="enter your name">

I realise my Aurelia bias is starting to show here, but in my opinion, I think the Aurelia approach looks a heck of a lot nicer and more JS syntax-like than the Vue bind:value approach. Not having to type a colon is a huge plus and it just looks neater.

Anyway, moving on. We are nitpicking here.

It is Fast.

There is no denying that Svelte is fast. The lack of runtime is the contributing factor here. The closer you are to the bare metal of the browser, the faster things will be.

The truth is, all frameworks and libraries are fast. When it comes to speed and performance, the contributing factor is rarely the framework or library itself, it is the user code.

Start pulling in various Node packages like Moment, adding in features such as validation and routing, and ultimately your bundle size is going to grow significantly. The end result might be the framework or library itself (even those with a runtime) accounts for 10% of your overall application size.

This is why I always tell people to be wary of benchmarks. Sure, benchmarks might look impressive, but they are not indicative of real-world conditions where things like latency, bundle size, what libraries you are using, and how you write your code are really the determining factors.

I think considerations to how a framework or library lets you author components and write code, what its features are, and what it allows you to easily and not easily do are more important than its speed.

To put things into context, there are still many AngularJS 1.x applications out there in production, which are still working fine. I also know of many Durandal, Knockout and Backbone applications still being used which are also working fine.

The generated code I have seen from Svelte applications is surprisingly readable as well. Usually compiled code is not easy to read (for humans) at all, so I was really surprised.

Svelte Exposes The True Complexity of React

For years, React has hidden behind the claim that it is the V in MVC, that it is a simple and a humble view component library. Anyone who has ever worked with React on an actual application will tell you that you never just need the view part.

I cannot recall a time where I have ever built a web application that didn’t have at least:

• Routing (the ability to define routes to different screens)
• The need to work with data from an API
• Form validation (not always, but more often than not)

If you want to add these features into a React app, you have to glue them all together. Because React utilises a Virtual DOM, the ability to just drop in and use any library that touches the DOM is not possible.

The problem with React itself (without turning this into a post bashing React), is that it is too heavily invested into itself. It is also responsible for perpetuating FUD in the front-end ecosystem on quite a few fronts.

React popularising Virtual DOM (and later on, Vue) would result in a lot of FUD around the DOM. When people tell you that the DOM is slow, they’re responding as a result of being programmed by the React community which drunk the “DOM is slow Koolaid” a few years ago.

Svelte has proven that the DOM is not slow. Although to be fair, Aurelia has eschewed the Virtual DOM (in favour of reactive binding) since it launched in 2015 and managed to keep step with other frameworks and libraries for years (upcoming Aurelia 2, even more so).

Now that React has introduced the concept of hooks into their library, it is yet another thing for developers to learn. Solutions like Svelte which do not require you to learn abstractions and ways of authoring applications definitely feel lighter and saner in the face of React.

Cognitively React requires a few React-specific ways of working which just adds to the learning curve. The React of 2019 is not the React of 2014, that is for sure. Authoring applications using Javascript and HTML is kind of refreshing.

Lack of ability to functionally compose views

This is one of those downsides of Svelte that some developers will struggle to look past. It requires you to use script tags and HTML to build your Svelte components. This means you are forced to use its templating syntax like #if, having to use #each for looping.

For developers who have had a taste of “pure components” where all components are written in Javascript, this is going to be a hard pill to swallow.

No TypeScript Support (Yet)

Right now, there is no official support for TypeScript in Svelte. If you are not a TypeScript user or perhaps you work with Vue 2 which admittedly is not much better at supporting TypeScript, then this will not be a dealbreaker for you at all.

If you are like many other developers who realise the future is TypeScript and have switched over, the lack of TS support is going to be a dealbreaker for you. Some developers have gotten it to work sort of using hacks, but not ideal support by any means.

Conclusion

I think what Svelte has brought to the table is going to kickstart some innovation and competition in the front-end space. While React has been trudging along for quite a few years now and Vue picking up popularity as well, it’s nice to see some new thinking that doesn’t revolve around a Virtual DOM or leaky abstraction.

Rest assured, you best believe that other frameworks and libraries are not going to sit idle while Svelte comes in and pulls the table cloth right off the dinner table.

The AOT compiler coming in Aurelia 2, for example, is going to optimise your Aurelia applications to a high degree stripping away runtime and unneeded code. Angular has been focusing their efforts on improved AOT compilation with the Ivy compiler and renderer and other options are also focusing their efforts on the compilation as well.

Even after playing around with Svelete just briefly, the lack of resulting code and marketing spin was refreshing to see after years of other players in the industry seemingly perpetuating immense amounts of hype.

Having said that, the safety and stability that I get using a featured framework (in my case, Aurelia) still feels too hard to beat.

I think Svelte is definitely going to get more popular and for non-complex UI’s it would be a great choice over React or Vue, but I still have hope that one day that Web Components becomes the norm and we see light abstractions on-top of WC that just compile to Web Components behind the scenes.

I would love to see how Svelte scales in a large-scale web application. Not specifically in performance (because I think it would remain fast), but rather code organisation, maintainability, testability and how easy it is to bring new team members up to scratch with an existing codebase.

Massive kudos to Rich Harris and everyone else who has worked on Svelte. I can definitely see the hype around Svelte is more than warranted and in the end, competition is healthy. We need fresh thinking and solutions to help drive standards and the ecosystem forward as a whole.

Being a parent, as any other parent would attest is rewarding, but hard work. And nothing has made modern parenting more challenging than YouTube.

We managed to not expose our firstborn son to any TV or screens until he was two. We were doing well until we had a trip booked from Australia to the UK, which was a 23-hour trip. We bit the bullet and bought an iPad to load up with some activities for the journey and some carefully selected YouTube videos.

Things started innocently enough, until the YouTube app, when connected to the internet, would begin automatically playing similar recommended videos. I do not recall the exact moment, but eventually, Ryan’s Toy Review found its way into our lives.

If you are a parent of children who watch YouTube, there is a good chance they have come across Ryan’s Toy Review or one of its other associated channels like Ryan’s Family Review.

Ryan’s Toy Review might have started out with good intentions, but estimates place the earnings of the channel at around $22 million (US Dollars) per year. When you are earning that much money, you are a business, not an innocent child playing with toys.

The parents regularly feature in Ryan’s videos, the mother has a very irritating voice and is always shouting. The father seems to be softly spoken and somewhat likeable, but the mother takes centre stage, and it sometimes feels like she is the subject of the video, not Ryan.

Watch any of the videos produced lately on the channel, and you will notice they all have one thing most in common: they’re advertising Ryan branded products. None of the videos has any kind of disclaimer on them that says they are promoting paid products either. Sometimes a flash of text or a few seconds of the video will tell you it’s a promotion, but intentionally short.

In one of the videos, Ryan visits a Colgate factory and does a tour, the video starts off innocently enough until you realise it’s an advertisement for Ryan branded dental products. The way they frame it is Ryan just spends a fun day making toothpaste and mouthwash, like it’s a visit to the museum.

The ironic thing about these videos, is there are numerous ones of Ryan eating and playing with chocolate, talking about McDonald’s and other unhealthy forms of food that would cause decay.

People are beginning to notice that Ryan’s Toy Review and associated channels are deceiving and tricking children into buying their products. So much so, a complaint has been registered with the FTC.

And it is clear the parents are reaping the rewards of the success of the channel. They started another channel called Ryan’s Family Review, where they travel and do things most kids do not get to do. Perhaps most desperate of all is the channel his parents started called The Studio Space.

We blocked Ryan’s Toy Review and Family Review channels, but one channel which is new is Studio Space (since blocked). Most of the videos centre around Ryan’s parents and other weird guests, with a rare appearance from Ryan himself from time-to-time.

I get the impression Ryan’s mother Loann, loves fame and money because she appears the most in these videos. It feels like a desperate attempt to pivot, knowing that Ryan is getting older and becoming more interested in video games like Minecraft over toys.

The Studio Space videos see Ryan’s parents acting out role plays, playing with toys, pushing cardboard boxes into inflatable pools and other nonsense in a desperate attempt to retain their large following and subsequent profits from that following.

In the regular YouTube app, you cannot outright block a channel from being watched or appearing. However, if you download the YouTube Kids app, you can. We actually have blocked the channel in our house, and I recommend everyone else does the same.

Ryan’s Toy Review is a business selling products to vulnerable children disguised as innocent toy review videos.

As ubiquitous as state management has become in front-end development, it is still a confusing magical black box to most developers. Data goes in, data goes out, and nobody thinks about what happens in-between.

Some developers believe the answer to the question in my title is: always. While some don’t believe in using state management at all and if you’re like me, the answer is: it depends.

When state management gets added to an application that meets the criteria for using it, a weight gets lifted off your shoulders, and things make sense. Prematurely introduce state management or use it in places where you shouldn’t, and your life becomes a tangled mess.

The complexity of state management starts to get even more confusing when questions arise around best practices for working with API endpoints or dealing with forms. The answers are primarily opinion-based once again.

Avoid state management for forms

I cannot stress this enough. I have seen developers implement hacky solutions to working with form inputs and state management, and it’s a clear case of the right tool for the right job. While Redux and other state management solutions have plugins for dealing with forms, why inflict pain on yourself unnecessarily?

You might not agree with me on this one, and that is okay. However, every single time, I can recall seeing state management, coupled with forms, was unnecessary. You only have to Google to find a tonne of people asking for help getting state management to work with forms to see why you shouldn’t.

Forms are often always ephemeral state, meaning the data only exists temporarily. An example of a form might be login form with a username and password or a form for adding a new product to your store. You enter the data and dispatch an action, the form gets cleared, and that’s it.

Instead of replicating and nesting properties in a massive state tree for one specific part of your application that some users might not even use, use local state instead. If you’re working with React, this would be local state within a component (using something like the useState hook) and similar with Aurelia or Vue, local state within your view-model or component.

Just because you can doesn’t mean that you should.

Working with API’s

Depending on your state management solution of choice, the approach for working with API’s can vary depending on plugins and workflow. However, the principle is the same. Your action(s) make an API request and update the state, or you make the request and dispatch an action with the response.

I know in Vue’s VueX state management plugin, many in the community advocate for making your API requests inside of your actions. There isn’t anything wrong with that; however, in Aurelia’s state management library Aurelia Store, I advocate for making the request and then notifying the store.

It doesn’t matter how your data gets into the state, more-so what kind of data you are putting in the state is what truly matters.

Do I need this data again, will I use it more than once?

State management is recycling your data. Will you need that value again in other parts of your application? Use state management. Do you only need to store the value temporarily and reference it in a specific component, only for it to be discarded shortly after that? Don’t use state management.

Asking yourself the following question should be the litmus test you apply to your development workflow. Will you need this value again and will you need it in other parts of your application? Type it up, print it out and hang it up on your wall.

The purpose of state management is not to play the role of “random kitchen drawer full of miscellaneous items”, it exists to make cross-component and cross-application data access easier as well as ensuring the integrity and shape of the data remains intact (in part due to Javascript passing everything by reference).

Using GraphQL?

You might not need state management at all. GraphQL offerings like Apollo offer an all-in-one package for working with data, including state management like functionality that makes syncing and working with your GraphQL server a breeze.

While there is nothing stopping you from using GraphQL with state management libraries, and some GraphQL clients might require them to meet your needs, in many cases you only need one or the other.

State management can introduce unnecessary complexity

If you have ever seen a React + Redux application, you know what I am talking about, a mess of folders and files scattered through your application. You have to open up seven files to change something, and it’s a tonne of cognitive overload.

Something I want to make very clear here: the complexity of using something should never be the deciding factor in whether to use it or not. The next time you start on a new application, don’t be so quick to add in state management but don’t leave it too late.

If you’re validating an idea or prototyping, it can slow you down having to write all of the boilerplate most state management libraries require. Sometimes you need to be “agile” and flexible, and state management can be quite rigid and the opposite of that.

When it comes to state management, do what works for you. Trust your intuition, and if something feels complicated and unnecessary, your gut instinct is probably right. Posts like these are great as a guide, but ultimately you should never take everything as gospel.

Testing is a crucial part of any modern development process. If you’re not testing your code, you might as well be writing it blindfolded and hoping when you push to production that it works, if the company doesn’t go bankrupt from all of the bugs first.

But, I am a realist. Being honest, we all start out wanting to build things right. We want to test everything, writing both unit and integration tests to make sure everything works as intended. The company you work for might even allow for time to write tests until reality hits you on the back of the head.

Priorities change. The higher-ups want the product you’re working on to ship in two months, and there is easily four months of work in Jira, it’s going to be a mission to get it all completed in time.

In my experience, tests are usually the first thing to be removed in the face of more pressing priorities (like actually building the product and making money).

A word on Test Driven Development (TDD)

I have always been a fan of test-driven development. And I have been fortunate to be in a position where I have been able to explore TDD, and when it works, boy does it work. By works, I mean when a company agrees to invest the time into a test-driven development process.

Every project I work on, my first thought is “TDD would be great for this”, but once again, priorities shift, and it becomes hard to justify the short-term investment for the long-term gain that TDD provides. Even if your entire development team wants something, management gets the final word, and it all comes down to money in the end (we’ll talk about that later).

You need tests

In an ideal world, we would all be writing our tests first and then making our code make them pass, make them fail, make them pass. A good test not only helps you design clean code, but it also has the added benefit of documenting your code as well.

If TDD is more time consuming and harder to justify to your company, does this mean you give up on writing tests completely? Heck no.

In any medium to large application, tests are as crucial as decent server infrastructure; they should be the oxygen to your app brain. No oxygen and the brain will slowly die.

Inevitably, many developers end up resorting to TAD (Test After Development) because it’s easier and faster (at least initially). Writing the code first and then going back and writing the tests after the fact. It is not super ideal, but any tests are better than no tests.

Many would argue that if you get into the habit of TDD, over time, you will get faster at writing tests and code, that the long-term benefits outweigh the short-term caveats. The buy-in from stakeholders is the hard part. If it were easy, everyone would be doing TDD.

The longer you work on a project, the more crucial tests become. As the scope widens and feature set increases, things are more likely to break, and some of your architectural decisions early on are bound to come back and bite you (something that TDD would help you most likely avoid).

The whole point of TDD is that initially, work takes longer to complete than not prescribing to TDD, but your code will be more stable and less error-prone.

An experienced surgeon doesn’t rush to cut you open and perform heart surgery right away; they take their time and slowly get the job done. Programming is not heart surgery, but if you’re working on critical systems where functioning clean code is essential (like a space shuttle or nuclear power plant), it’s equally as important you get it right.

However, it all comes down to cost

The deciding factor in any decision you make within your company always comes down to money. The short-term benefits of TDD are hard to quantify, and if you do your job correctly, the number of bugs and refactoring work you need to do will be substantially lower (almost zero), but how do you prove that to non-technical higher-ups?

You can’t. It’s all well and good to say we have fewer bugs since adhering to TDD principles, but it is challenging to prove that TDD is the reason for that and not just increased familiarity and skill-level being the main factor.

• Does it take more time to finish a task? Yes.
• Will it cost the company more time and money? Yes.
• Will there be a learning curve for inexperienced developers (especially juniors)? Yes.

Once again, you could argue that writing the code and then writing the tests, going back and refactoring your code and then having to fix your tests takes a lot more time using TAD: you’re right. Looking at TDD through neutral coloured glasses, there are more benefits than downsides if time is not an option.

But, the industry is weird. Many managers still measure the value and productivity of developers by the number of lines of code they write and commits they’re pushing up. And what produces the most lines of code and commits? TAD. It’s inefficient, but even non-technical people can see you look busy.

Developer A and Developer B side-by-side, Developer A is writing and shipping code faster than the other. It might be laden with errors and horrendous compared to Developer B’s well-architected and clean code, but it works and if there is one thing managers love more than saving money, it’s shipping code on time.

Conclusion

If you can’t convince the company you work for to give TDD a chance, TAD is still an acceptable albeit less than the ideal alternative of no tests. As long as you have tests, there is always room for improvement.

All eyes are on Facebook at the moment as it was revealed that Cambridge Analytica a third-party company exploited loopholes in Facebook’s platform to obtain as much as 87 million Facebook users information through some fake survey application.

While this is a terrifying situation knowing that such a large amount of data was harvested, can we honestly say that we are really surprised something like this has happened?

Facebook isn’t alone

It’s easy to blame Facebook, they’re the biggest social network and they know a lot about us, but they’re not the only online company with a trove of information.

Are we really naive to believe that Apple, Google, Amazon and numerous advertising platforms don’t have the same level of data (if not more) than what Facebook has? Can we honestly say that we know what data these other companies have and of whom they provide access to?

We knowingly give up so much about ourselves, all so Google can tell us how long it will take to get somewhere in Google Maps or so Siri and Google Assistant can tell us funny jokes.

We go out and buy Amazon Echo’s, Google Home’s and Apple Siri Speakers and let them listen to our every word. We knowingly allow companies like Google to track our search history, our viewing history on YouTube.

I can’t help but feel as though Facebook is being used a scapegoat here, if only US senators held other companies and themselves as accountable for data, and acted more harshly when a company is hacked and user information is leaked.

What happened with Facebook is inexcusable and alarming, but we’re focusing on one part of the problem here. There is more to the privacy puzzle than Facebook, let’s get serious about privacy and equally question all large companies with access to a lot of our data.

Hello Equifax

In 2017 arguably one of the largest data breaches so far was when Equifax was hacked, exposing 147.9 million Americans, as well as some Canadian and British nationals information including; drivers licence numbers, social security numbers, tax identification numbers, email addresses (issue dates and states).

And worse of all, it took Equifax four months to report the hack. For four months, information on over one hundred million people was circulating dark parts of the web. Unacceptable.

Not only was the hack bad and failure to disclose it in a timely manner, but Equifax routinely botched its reporting on the hack, failing to disclose more information than they had led on was taken, and revising the number of affected people a couple of times.

Did Equifax get paraded in US Congress and grilled by senators for their recklessness like Mark Zuckerberg? No. Did Equifax get threatened with further legislation and regulation, or maybe a fine? Nope.

The Consumer Financial Protection Bureau (tasked with protecting consumers) who was investigating the incident stopped investigating Equifax after a change in leadership.

To put that into perspective, Facebook users had some of their information harvested (their likes, interests and so on) but nothing that could be used to steal your identity or understand your financial position, but Equifax exposes some seriously private details and nothing happens.

Russia. Russia. Russia.

This whole situation reeks of a strong agenda, like an aged cheese or infected toe and it’s called Russia.

You see, Russia is a hot topic at the moment. This whole situation isn’t about privacy, US senators don’t care about your Facebook likes and friends list being harvested.

But you throw Russia into the mix and say the data was used to manipulate the 2016 election and all of a sudden it becomes more interesting and appealing, it’s a scandal now and scandals are great to push an agenda.

Conclusion

We can slap the handcuffs on Facebook all we want, but you know and I know that Facebook isn’t the only company that has information about you and isn’t forthcoming with how it is used or accessed.

We just witnessed a small-scale atomic data explosion, I am sure we are going to see privacy explosions on the same scale, if not bigger.

I still fondly remember when Medium first hit the scene. Everyone loved the quality of the writing and variety, every article I read was seemingly well-written and of high quality.

Fast forward to 2017 and Medium has become the equivalent of a never-ending TED Talk. Everyone wants to improve my life and tell me how to be a better person.

The good articles are still there, but there is a serious imbalance of content going on, with the “X things you need to do for a better life” or “How to be a better X”

At the time of writing this, here are some of the titles of Medium articles under the popular topic. As you’re reading them, picture someone in a argyle sweater holding a piccolo latte and wearing black rimmed glasses on a TED stage reading these out as they pace the stage back and forth with long pauses between their words.

• Our clothes can change who we are
• It’s a Good Thing Some People Don’t Like You
• How To Deal With Uncomfortable Emotions And Reshape Your Identity
• 5 Mental Biases That Cause Poor Decisions
• 30 Behaviors That Will Make You Unstoppable
• Willpower Doesn’t Work. Here’s How to Actually Change Your Life
• I Once Talked To Seth Godin On The Phone: Here’s How It Changed My Life and Business

I am not saying there isn’t a market for these kind of articles and heck, I would be lying to you if I said I hadn’t read one or two of these do-gooder, improve your shitty life articles on Medium before.

Medium has become a real life living TED Talk with some of Tony Robbin’s, “my life is so great and here is how your life can be great too” mantra injected in there somewhere.

It is for this reason, I find myself not going to Medium as much as I used too. The content doesn’t appeal to me and when it does, there is usually a downside somewhere along the way.

It’s not that I am a negative person, I just find these “positive” improve your life articles to be mostly full of shit. I often wonder if Tony Robbin’s truly believes in what he preaches at his expensive events or if he just likes the feeling of money against his skin as he bathes in it on his elevated mansion overlooking the sad common folk.

I follow programming topics on Medium mostly and even then, for Javascript specifically it has devolved into comparison posts pitting frameworks and libraries against one another.

The comparison articles on Medium (which I am guilty of blogging here myself) are mostly always poorly written and heavily one-sided. It’s rare you encounter a comparison article that is balanced.

Then there is the other side of Medium if you’re a content writer: lost ownership.

When you publish your content on Medium, you’re giving up control. Sure, you get to publish on a large centralised content platform with huge reach, but you’re beholden to a platform which exists to make money for its investors and pay its staff.

This means Medium can change the rules midway through the game and you have to deal with it. If Medium decide you have to start paying them or GTFO, you have a loaded gun pointed to your head (a bit of a theoretical, but still).

Self-publishing is the future of content, not publishing articles on a VC backed content platform.

If you’re a developer, then there is a very high possibility that at some point, you’ve needed to Google an issue and you encountered a StackOverflow question and got the help you needed.

Personally, I hit StackOverflow a few times per week, sometimes on a daily basis if I am tackling something I do not fully understand.

All of the developers I know use adblockers (I use uBlock Origin in Chrome) and by default blocking advertisements everywhere. But if there is one site that deserves to be whitelisted: it’s StackOverflow.

For general information about a wide range of topics, we have Wikipedia and for answering our development questions: we have StackOverflow.

They ask for no money, you don’t need an account to use it and the advertisements they do show are non-intrusive and tasteful (unlike a site like The Pirate Bay).

And above all else: StackOverflow don’t care if you block ads, although they would prefer it if you didn’t. The value of StackOverflow cannot be understated, it is the Wikipedia equivalent for developers and they deserve our support.