I’m just appreciating the concept of Reactive Programming right now. And I’m seeing how ReactJS has made it easy. From what I understand, the notion of reactive programming is that if you change the state of “something”, anything else that depends on it should also automatically (or reactively) update itself. A simple example can be with Excel spreadsheets. If in cell C1, you have the formula =B1+A1, any time you make a change in B1 or A1, C1 will automatically (aka reactively) update. You do not have to manually go into C1 and re-calculate the value.

With ReactJS in javascript, they’ve made it much easier to do reactive programming. Consider the simple code below as an example.

<html>

<head>

<script type=”text/javascript”>

var arrVals = ['First Row','Second Row','Third Row'];

$(document).ready(function(){

// populate template with content

for(let x=0; x<arrVals.length; x++)

{

addItem(arrVals[x]);

}

$(‘button’).click(function(){

addItem($(‘input’).val());

});

});

function addItem(text)

{

let item = document.createElement(‘li’);

li.innerHTML = text;

$(‘ul’).append(li);

}

</script>

</head>

<body>

<div id=”container”>

<input type=”text” value=”" />

<button type=”button”>Add Row</button>

<ul></ul>

</div>

</body>

</html>

This code should be pretty straightforward right? When the page first loads, you’ll get a text field, a button and a list with items First Row, Second Row and Third Row. If you press the Add Row button, it will take the text in your text field and add a new row to the ul. The process by which the UL renders new LI after Add Row is pressed isn’t particularly reactive. I say this because every time you press Add Row, a developer/custom defined function called addItem() needs to fire in order to create the new list. This might seem trivial in our example. But if you have a more sophisticated html mark up to define a much more complex user interface, always defining new html elements on the fly can be a very labourious and tedious effort that makes it very difficult to test.

A relatively more reactive approach would be after you press Add Row button, the text value from the text fields get stored in a state (eg. in an array as a property of a class). Just saving that value to the state should automatically render a new interface without you needing to do anything.

ReactJS has an approach to handle just that. Below is ReactJS code that achieves the same objectives as the javascript code above:

Outputs the output of MyProject.render() into the #container div. I’ve also passed in the initial 3 rows of content as an array into MyProject.

So here’s the secret sauce — any time you fire the this.setState() function (which populates this.state), and if this.state has changed some values, the React object will automatically fire MyProject.render().

This makes it much easier to maintain and update user interfaces when content has changed. I don’t have to waste time writing a whole bunch of code to maintain / render my user interfaces every time the data/content has changed. I can just rely on my render() function to re-fire any time I’ve updated data.

Launch phase is the time leading up to launch. There are three rules to follow during the launch phase.

Rule 1 – No functionality revisions leading up to launch

Downgrade items like “Re-use the preview functionality from detail mode on list mode”.

Although an important feature to have, and relatively easy to implement, do not enhance or revise last minute or you risk breaking everything else. General rule, no functionality revision leading up to a launch.

Rule 2 – Tickets can be more than Open and Close, they can change priority

Downgrade tasks that have been partially addressed.

For example, the original task do not allow dollar signs and commas in the goal amount text field, which is a legitimate concern because it’s some people expect to enter these characters even though our system does not allow it for this field. The ticket was addressed, but a QA person discovers negative amounts weren’t being saved properly. This later realization is different (even though it’s related) from the original issue and is UNLIKELY to happen, and can be dealt with after the launch.

General rule, a task’s priority can change over time – it can start as mandatory, a temporary / partial solution can be implemented, and then it can become nice-to-have. Tick 7257 isn’t a priority anymore. So you don’t close the ticket, you simply downgrade it.

So back to general rule 1, we avoid functionality revisions leading up to launch.

Rule 3 – do-able tickets leading up to launch

Things that should be addressed leading up to launch are:
- bug fixes such as the reporting of incorrect values, and functionality that actually prevent usage
- text revisions like change 1 people donated to 1 person donated
- changing a color here and there

When you guys look at a web software platform, can you date the style of development to a particular time period when it was popular?

Examples from my experience:

When I first saw eFront, I immediately recognized it as being identical to vTiger, SugarCRM and Moodle. So I think popular PHP architecture approach for 2005 to 2010. When I heard that eFront was upgrading its architecture to a more modern MVC style, my reaction was, “good idea, because eFront is getting more popular, and the new-age developers aren’t experienced in the old-way of development.”

When I first saw Ruby on Rails in 2011, I immediately thought of my experiences with Code Igniter. I learned later that Code Igniter’s MVC was actually inspired by Ruby on Rails, so it was the other way around. Around that time, due to RoR’s rising popularity, every framework started to copy it. So we saw massive upgrades to Zend Framework, .NET framework, CakePHP, Django etc… My reaction at the time was, “so this new way of doing MVC is really here to stay now? I guess I might as well start upgrading and organizing the Evermight tools in the same way.” So any time I see folders clearly labelled as Model, Controller, View, I reminice about the 2010-ish years. Since 2012, I haven’t seen any major MVC framework make as drastic of an architectural change as it did in 2010-ish…

When I look at the earlier Evermight projects (Startmission and earlier), I remember why I wanted to follow the .NET 3.5 approach of code behinds, which is the popular approach for most web application development between 2005 to 2010.

When I see spaghetti code from a supposedly veteren web developer, it very well could have been a popular web development approach prior to 2005 (I wasn’t a developer before this time period, so I can’t say for sure whether it is or not) given the lack of web development frameworks in those days. Or maybe they are just bad-coders.

I remember I quit my job working as a developer at University of Toronto in 2007 because I couldn’t convince the senior developers at the time of adopting modern web development practices. One example was when the senior developer’s were reluctant to adopt object oriented programming, which may seem shocking to new-age developers reading this post 2014, because they may have forgot about the poor OOP support prior to PHP 5.x. In 2007, PHP 5.x was already well received by developers who were taking advantage of more advanced OOP principles. As for the environment I was workign in, none of the senior developers believed in OOP. Some didn’t even believe in MVC (in situations where it was clear it should be used). And because ob_start() and ob_clean() was a new introduction to PHP 4, the old timers still did things like this:

Being the new guy with 3 years of experience under the belt, swooned by the latest development practices and web technologies, I tried to convince my seniors of adopting popular industry practices. I tried to convince them that properly separating database code and presentation code would make things more maintainable. I tried to convince them that using Javascript to manipulate the DOM was really cool (if you didn’t care much about IE 5, but it worked great in Netscape and FireFox). I mentioned that AJAX would revolutionize web development practices ( I didn’t try hard to convince them to use it because I couldn’t even get past the step of convincing them of the power of Javascript for DOM manipulation). I tried to convince them to use more advanced CSS2 capabilities for presentation instead of using HTML tables for layout.

In the end, I couldn’t convince anyone of anything. I demonstrated popular projects of the day like Joomla, Google Maps, Facebook that leveraged these new dev practices. My senior developers were un-moved. I thought maybe I had to de-mystify the magic behind these new technique by showing them how it’s done. So for years, I freelanced at nights and built my own projects, each project taking roughly 40 to 160 hours of development. Each project increased in complexity. The most memorable one was when I built an interactive windows-2000-like desktop with a start menu, drag-able icons, and an AJAX based text editor that saved to a database. I demonstrated these to my seniors during the day every week. I would describe their reactions as, “Oh, that’s a nice gimmick, but it won’t last.” The most senior developers in the department went as far as to argue against my work and approach on the basis that PHP wasn’t meant to support OOP, so I should stop. Or that AJAX wasn’t supported on all browser, so I should stop. Java is too heavy for web applications, that’s why web-based Java applets are dead and we have Flash, so I should stop. The list of reasons for why I should stop ran on. I ultimately did stop. I stopped working at University of Toronto. I went to Toronto Star.

I didn’t know what else I could do at U of T. I realized sometime later that there really wasn’t anything I could do to convince the senior developers of doing things the new way (new for it’s time). The senior developers have a proven approach to solving business problems in a manner that meets the business and budget requirements. They’ve done it time and time again. Their approach survived it’s time. All the latest industry practices that I was presenting were coming from me…me being the person who has yet to demonstrate how, not if, but how my approach would hold up to the challenges of constantly changing business requirements and ever decreasing budget. I emphasize how in my previous sentence because I think some senior developers were starting to understand the approach would work, especially since large companies were using it, and since I demonstrated even junior developers like me could pick it up, but they needed a seasoned individual (ie. not me) to guide them through the difficult challenges that come with doing things for the first time.

Today, I feel like I’ve become the dinosaur. Today, I run my business during the day. At night, I either run the business some more or I code. No where am I as up-to-speed on latest development trends as I once was, since I’ve diverted the majority of my attention to improving other areas of my professional game. There are developers on the team now asking me to use this design pattern, and that new framework, and this and that. And while I acknowledge many of the popular practices are proven in industry, I am reluctant to take the risks of deploying them on large scale projects without the guidance of someone who’s done it before (ie. hire expensive senior technical architect better than me). Despite all the latest and greatest tools, I just know how long it would take me to do things my-way, and I have the confidence of recovering from any disasters that result from my way of doing things. I don’t have that same confidence in my team in their ability to rebound from disasters with the new tools and new processes without my deep involvement. If I did, I would be all gung-ho about it. (More on this further down). I have full confidence in my team doing things the current way, and that’s what I’ll default to.

Although I haven’t done the greatest job at it, I try to encourage the team to stay up to date on development practices and tools by letting them exercise whatever they want on particular projects.

Examples include:

- asking a developer to build an event-conference tool using .NET latest technologies. But there wasn’t enough guidance from me, and the developer lost sense of priorities, and it became very stressful reaching deadline

- being the guinea pigs for the second release of PhoneGap on a rather mission-critical project, only to discover PhoneGap was still too beta to be the leading cross mobile development platform at the time, again it became very stressful to meet timelines (I experienced health issues where the whole left side of my torso broke out in shingles for a month. The project was in such bad shape that I had to delay seeing the doctor until after we completely rebuilt the project and launched, hence living with shingles for a month…felt like I was living with really bad body shots (boxing) the whole time.)

- trying to learn node.js, which changed directions to ruby on rails, and changed again to sinatra, and changed again to just ruby, while trying to automate some tests. The reasons for the constant direction change was because I was in the early stages of learning these tools, and was just pivoting towards the right tool for the job (a still incomplete journey, which I can expect a few more direction changes).

- trying out some of the latest HTML5 development tools to build really engaging and interactive video games

And there are a slew of many other examples since 2008. In doing so there were two big challenges I’d like to mention.

CHALLENGE ONE
The first challenge was stress. Between the years 2011 and 2013, I was still very much a fan of the “latest and greatest” technologies out there. But in 2011, I was also rebuilding Evermight. The previous partnership I was in completely collapsed on my end, and I was re-starting from scratch. A big problem arose during this time because I was consulting and developing with the “latest and greatest techniques” mind set in a boot-strapped re-start-up. Everything went awry. Unexpected technical difficulties arose in every unanticipated direction (eg. the .net conference tool and hte phone gap experience). Projects almost failed if it hadn’t been for people putting their families and marriages on the line, sacrificing physical and mental health (clients first, doctors later) and incurring additional debt. Oh, and maybe throw a touch of “sorry honey, but I won’t be home for Christmas holidays” to the list.

The team’s universal mandate for corporate improvement in the coming year of 2014 was less stress. Developers said they can not sustain that level of intensity for another few years. The only reason they put up with it for so many years, where most people would have quit after two months, was because my employees were childhood friends…so I know where they live, who is most dear to them, and… you get the idea. Realizing exploitation isn’t the healthiest way to run a business, I came up with a plan to solve the problem. I have to control my fetish for the “latest and greatest”, especially on the mission critical projects. I need to give the team and company time to settle down with its existing tools and processes. I should apply something liek an 80-20 rule, where 80% of the times, we do things in a way that’s proven to work and take as little risk as possible. The other 20% of the times, we try out new tools and processes on low-priority projects that won’t hospitalize us if things go wrong.

Now that 2014 is coming to an end, i would say that we met our 2014 objective of reducing stress. No marriages were destroyed as a result of working at Evermight. Although some of us have visited our family doctors, at least no one was hospitalized for several days. And some of us decided to take vacation and celebrate things like birthdays.

CHALLENGE TWO
Despite the success of reducing stress, a second challenge took it’s place. We were no longer advancing our technical skills the way we’ve been accustomed too. The 20% for innovation isn’t sufficient. For example, I’m leading the way with the automated tests and trying out new frameworks. But I am the least suitable person for this assignment because business operations is already more than a full time job itself. As for the other developers on the team trying out new things, the efforts are short-lived for various reasons such as self-motivation, unclear competing assignments due to lack of project management, steep learning curves, lack of clear business objectives etc… The inability for the team to sustain their innovative endeavours prevent these new tools and processes from maturing to a state where they can be used on larger and more critical projects. In the past, we solved this problem by using these new tools and processes on many mission critical projects, which forced many of us to kill ourselves to deal with all the unexpected scenarios. But without the incentive of a gun pointed at our heads, we’ve kinda just stopped.

So how do we make everyone on the team happy? How do we continue to improve our technical abilities while also avoiding the stress of 2008 to 2013? I’ve come to the conclusion that this will not happen internally. I think the solution is to hire seasoned external consultants to help us upgrade our processes. This will cost money, which I have yet to budget for. And now I feel like the guy standing at Best Buy looking at all the bright and shiny phones, contemplating whether it’s time to upgrade. My old phone which no one’s ever heard of still does everything I need it to do exceedingly well. But all the cool people have the latest phone. If I buy a new phone, it’s got to be more than just a cool factor. I need measurable differences in my day to day productivity. But new phones are coming out all the time. I can’t just buy a new phone every year. But if I don’t get the new phone, my friends will think I’m lame, and join another team. So when exactly should I buy the new phone? When exactly should I pay for the external consultant to upgrade our company?

Tough decision to make.

MISC
There are a few cards that I don’t like to play, but maybe I should. I like to say that I’ve dedicated the past 10+ years of my life to just my work. I purposely abstained myself from anything in life that doesn’t involve work. I even tried to cut out exercise (martial arts and boxing) only to realize that caused a lot of health issues that would ultimately collapse the business. So now I don’t feel as bad punching people in the face and kicking them in the ribs. If something doesn’t contribute to the business, then it must be removed from my life. If I were borrwo from religion, I would say I have sinned at times by accompanying my parents to the super market to do grocery shopping, and even worse, i enjoyed that experience. A sin because I broke the rule of doing something that has no direct benefit to the business. This mentality I have served me well between 2004 and 2010, the period when I personally experienced the most professional advancement. By 2010, it was no longer about just me. Evermight was established. The team was getting bigger, and I couldn’t do all the lifting myself. Not everyone has the same value system as me, so I can’t ask the same commitment of them since Evermight isn’t the social entrepreneurial entity I hoped it to be.