Code Ownership

Jay Field’s has an interesting posting on code ownership, “Experience Report: Weak Code Ownership”.  “Too many cooks in the kitchen” is unfortunately a problem I suspect we have all seen to many times on medium to large projects.  Stating the obvious, encourage consistency on a large code base over n years is difficult – its unfortunate that stakeholders who haven’t come from a software engineering background don’t really grasp the issues of such problems.

Primary Code Ownership approach sounds interesting, and reminds me of similar approaches from n years ago on projects which entailed a small team on the server and client portion of a project, with a primary owner for each team.   Clearly splitting a project into microservices style can only aid the project by avoiding a single individual attempting to set and govern code ownership of a large code base.

Its probably also worth noting Chris Conley’s recent comments on paired programming, and the killing of code reviews.  I think all to often code reviews are over hyped as a silver bullet solution.

We now fully understand the overhead of branches and pull requests. It’s not just the act of checking out a branch, writing a great pull request or the 200 LOC/hour for the reviewer.

User Story Map

Few useful links if your going down the User Story Map road:

• How to create a User Story Map
• Tips for Facilitating a User Story Mapping Session
• Story Maps – A Testing Tool After All

Time to React.js?

Eric Florenzano offers an interesting read on “Facebook just taught us all how to build websites”.  Essentially he is talking React.js.  Given the noise level on the web around React.js, coupled with the recent React.js conference, I’d be surprised if readers don’t already have a view of React.js, and haven’t seen their peers/colleagues watching the various presentations.

A recent blog from the BBC offers insight into the road they are taking with the BBC Homepage refresh.  Unsurprisingly, the BBC has chosen React.js:

On the front end we have embraced new technologies such as isomorphic Javascript using ReactJS. This allows us to execute our Javascript templates on both the server and the client meaning that users without Javascript can still load a basic version of the page. The technology will also allow us to quickly develop modules that can periodically update themselves with live data from around the BBC. All our scripts are bundled together using Browserify, which allows us to mix both the AMD and the CommonJS module loading systems. Utilising a mix of these two loading systems means we are not restricted in our choice of open source libraries because of the mechanism implemented in a particular module.

We are using Sass to build our stylesheets and BEM to structure our CSS selectors to ensure good performance. The Sass stylesheets are compiled to CSS during our automated build process, which runs using Gulp , our build system, both locally and on a Jenkins continuous integration server.

Gulp also runs our automated unit and acceptance tests, which are written using Mocha,

On the subject of client-server rendering, Tom Dale offers some thoughts.  It’s probably also having a read about ember FastBook, given the old Twitter posting on performance improvements from 2012.  One Big Fluke also offers a view on client-side templating with some test data to back up his views.

If you care about first paint time, server-side rendering wins. If your app needs all of the data on the page before it can do anything, client-side rendering wins.

As an aside, QuirksMode offers a view on the problems of Angular, and the reasons for the 2.0 course change, and thus the death of Angular.js:

Adopting Angular 2.0 would require them to allocate massive amounts of budget to rewriting code that already works. Also, I wonder how people from a Java background will like new coding style.

For these reasons I think many enterprise users will stick with 1.x and ignore 2.0. Of course, Google will eventually stop supporting 1.x. Thus I think Google’s attempt at cracking the front-end enterprise nut with Angular is going to fail over the next two to three years.

While the enterprise IT defection could be offset by an influx of front-enders, Angular has meanwhile acquired a bad reputation among them. Besides, yet another MVC framework is not what the front-end world needs right now.

Despite its serious technical problems Angular 1.x is a success especially among corporate developers with a Java background. The 2.0 rewrite is aimed at front-end developers, but may not reach them, and in addition will turn off Angular’s current following. I don’t think Angular will survive the rewrite.

Anyway, back to React.js.  Of note is the Atlassian posting on the rebuilding of Hipchat.  Atlassian is a cool company.  If they’ve decided to move to React.js its probably worth others taking note.

Finally, there is React Native.  Have Facebook provide us with a way to build browser and native apps in a unified way? “Learn once, write anywhere”

Bad Design Assures Bad Results

I’ve not read JavaScript Application Design yet, but was struck by the correctness of a statement made in “About the Book”:

The fate of most applications is often sealed before a single line of code has been written.

As I’ve blogged about before, all to often team lurch into code well in advance of actually understanding the problem they are attempting to solve, and lacking any sensible architecture and process.

Good design and effective processes are the foundation on which maintainable applications are built, scaled, and improved.

Technical Debt

Design Smells offer a single page on technical debt.  One of the key causes of technical debt often overlooked compared to the other items listed is “schedule pressure”.  Lack of understand of basic software engineering by stakeholders often means that teams are driven down a road where the only outcome can be technical debt, which in itself leads to other issues :(

Lean Enterprise

Got my hands on “Lean Enterprise: How High Performance Organizations Innovate at Scale” recently.  Found it a dry read.  However, the book has some classic comments:

The purpose of an organization is to enable ordinary human beings to do extraordinary things – Peter Drucker

Shareholder value is the dumbest idea in the world…[it is[ a result, not a strategy…Your main constituencies are your employees, your customers, and your products. – Jack Welch

Page 31, “establishing and trying to maintain effective communication within large teams consumes enormous amounts of capacity on large projects” – so so true.

Page 33, “As we execute the project, we discover new information – but since nobody wants their features cut, new information generally leads to move work, which is known as “scope creep””

Page 49, Minimum Viable Product – an experiment designed to maximize learning from potential early adopters with minimum effort.

Page 210, “CEOs can talk and blab all day about culture, but the employees know who the jerks are.” – Jack Welch

 

Stop Writing Dedicated Server End Points – GraphQL

There are numerous interesting presentations from React.js Conference 2015. “Data fetching for React applications at Facebook” is one such presentation well worth watching.  Specifically the comment at 7:52!  Shaping data should also help with reduction of bandwidth usage – your only sending the data you need, and nothing more.  This blog posting provide a view on batching requests – cut down the chatter.