Basics of fault-tolerant Promises in TypeScript

Recently I’ve been spending some time developing an Ionic 2 mobile app, which uses Angular and TypeScript.

I have noticed a couple places where my team has code similar to this:

someCallThatReturnsAPromise().then( () => {
  someOtherCallThatReturnsAPromise().then( () => {
}, (err) => {
  this.alertHelper.triggerErrorAlert("Hi an error happened: " + err.message);

This works but it suppresses errors . . .

Non-functional requirements are important yet often forgotten


Most software professionals in my experience lapse into talking about “requirements” while meaning only functional requirements. We seem to forget that there are also non-functional requirements, and that non-functional requirements are usually just as important as functional requirements to the end user or customer. Sometimes the non-functional requirements are more important.

Just to set some context, I would describe “functional requirements” as software requirements that . . .


Tackling Map.get()’s null-returning anti-pattern

In the beginning was Dictionary and HashTable, and they returned null when a call to get() was made. And the darkness prevailed over the land. And programmers found many NullPointerExceptions in production and confusion reigned on the face of the deep.

Then lo Map and HashMap were created. And there was great rejoicing, because their performance was greatly improved. And yea the royal order of code scribes did thus feel a great advance.

But confusion still reigned on the face of the deep, and null was returned on every call to get() . . .

More Peopleware quotes

“The business we’re in is more sociological than technological, more dependent on workers’ abilities to communicate with each other than their abilities to communicate with machines.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“The purpose of a team is not goal attainment but goal alignment.”
― Tom DeMarco, Peopleware : Productive Projects and Teams

“The statistics about reading are particularly discouraging: The average software developer, for example, doesn’t own a single book on the subject of his or her work, and hasn’t ever read one.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader, because that person would then cease to be a peer and the team interaction would begin to break down.”
― Tom DeMarco, Peopleware : Productive Projects and Teams

“Whether you call it a “team” or an “ensemble” or a “harmonious work group” is not what matters; what matters is helping all parties understand that the success of the individual is tied irrevocably to the success of the whole.”
― Tom DeMarco, Peopleware: Productive Projects and Teams

“So far, the results confirm the folklore: Programmers seem to be a bit more productive after they’ve done the estimate themselves, compared to cases in which the manager did it without even consulting them. When the two did the estimating together, the results tended to fall in between.”
― Tom DeMarco, Peopleware: Productive Projects and Teams


Open Office Plans – Excerpt from Peopleware

From PeopleWare: Productive Projects and Teams, Third Edition, by Tom DeMarco & Timothy Lister, © 2013 Addison-Wesley.

The bald fact is that many companies provide developers with a workplace that is so crowded, noisy, and interruptive as to fill their days with frustration. That alone could explain reduced efficiency as well as a tendency for good people to migrate elsewhere.

The hypothesis that qualities of the workplace may have a strong correlation to developer effectiveness is an easy one to test. All you have to do is devise a set of fixed benchmark tasks, similar to those that developers do in their normal work, and observe how well they perform each of these tasks in different environments. The Coding War Games were designed with exactly that purpose in mind.

In order to gather some data on the workplace, we had each war game participant (prior to the exercise) fill out a questionnaire about the physical quarters in which the work was to be performed. We asked for some objective data measurements of the dedicated space provided and the height of partitions, (for example) and for answers to some subjective questions like “Does your workplace make you feel appreciated?” and “Is your workplace acceptably quiet?” Then we correlated their answers to their performance in the exercise.

An easy way to spot the trend is to look at the workplace characteristics of people who did well in the exercise (based on a composite performance parameter) against those of participants who didn’t do so well. We chose to compare the top quarter of finishers with the bottom quarter. Average performance of those in the top quarter was 2.6 times better than that of those in the bottom quarter. The environmental correlations are summarized in Table 8-1.

The top quartile, those who did the exercise most rapidly and effectively, work in space that is substantially different from that of the bottom quartile. The top performers’ space is quieter, more private, better protected from interruption, and there is more of it.

Table 8-1. Environments of the Best and Worst Performers in the Coding War Games
Environmental Factor Those Who Performed in 1st Quartile Those Who Performed in 4th Quartile
1. How much dedicated work space do you have? 78 sq. ft. 46 sq. ft.
2. Is it acceptably quiet? 57% yes 29% yes
3. Is it acceptably private? 62% yes 19% yes
4. Can you silence your phone? 52% yes 10% yes
5. Can you divert your calls? 76% yes 19% yes
6. Do people often interrupt you needlessly? 38% yes 76% yes