OpenRasta: Today and tomorrow

The OpenRasta community has experienced a bit of a renaissance. And so it should, for there is much to rejoice about, and really cool stuff happening in the pipeline.

Because the time is right to reopen those communication channels we once had, the community is organising an OpenRasta MeetUp to talk about where we are and where we’re going, with great presentations, nifty additions to the openrasta family and a few reveals of where we’re going.

Come join us, at the just-eat offices, for an amazing evening of tech, beer and probably some food, on August the 22nd.

The Future of OpenRasta

Friday, Aug 22, 2014, 6:30 PM

Location details are available to members only.

41 Developers Attending

Talkers are to being scheduled, if you would like to talk please contact us.

Check out this Meetup →

Posted in Uncategorized | Leave a comment

Using Grunt-TSD w/ Node

If you are a fan of Typescript I assume you are well aware of the amazing type definition repository over at definitelytyped.org. This repository is great because it provides a definitive source for type definitions for pretty much every major JavaScript library.

If you are a fan of Node.js and JavaScript I have to assume that you are a fan of Grunt (or Gulp, your choice). You can use Grunt to automate pretty much every action needed when building HTML/JavaScript applications. Did you know you can also use Grunt to automate the retrieval of update type definitions from the DefinitelyTyped repository? Yup, you can. You simply need to use the Grunt-TSD plugin.

Here is how:

Reference the Grunt-TSD Plugin:
Simply NPM install the plugin using ‘npm install grunt-tsd –save-dev’

Add reference to the plugin inside your Grunt Script:
grunt.loadNpmTasks(‘grunt-tsd’);

Create a tsd.json file
In my opinion it is a bit cleaner to put your tsd configuration external to the grunt script, because of this I am following the path of creating a tds.json file. Make sure you create this file local to your gruntfile.js file. Below is my sample tsd.json file
tsdjson
Please note that the Path:typings entry in the tsd.json configuration is configurable. I wanted my d.ts files put into a ‘typings’ folder in my root. Of course you can change the name or location of this folder if you wish.

Download and install a Type Definition
In order to use a Type Definition you need to install it via TSD. To do this open your cmd prompt and CD into the directory which has your tsd.json file. Once there you can issue the following command ‘tsd query [package name] install -s -o’. This will install your package and update the tsd.json configuration files. For a full overview of the TSD syntax check out the TSD readme

Adding the TSD configuration to your Grunt file
After you have created your tsd.json file we need to create our configuration node inside of grunt. Below is my sample configuration.
tsd

Add the TSD task to a Registered Task
Once you have your TSD configuration node setup the last thing you will need to do is to call this from one of your Registered Tasks in your file.

Once you have all this setup you should be ready to roll. Simply issue a Grunt call to your configuration task (or use Grunt tsd) and watch the magic happen. To validate this worked as expected simply check you typings folder.

Till next time,

Posted in Grunt, TypeScript | Leave a comment

Quick Hit: What Do Your Customers Really Want?

The famous Harvard Business School Professor Theodore Levitt famously reminded:

“People don’t want to buy a quarter-inch drill. They want to buy a quarter-inch hole!”

He’s right. Similarly, your customers, whether other developers, other departments, or external customers don’t want to buy Agile, scrum, lean, test-driven development, domain driven development, continuous integration, C#, VB, Node, JavaScript, Roslyn, or any technology/language/tool/method. They want to buy what it enables, the solution, the hole.

 

Posted in Quick Hits | 1 Comment

On Programmers Productivity

This morning I stumbled on How to destroy Programmer Productivity by George Stocker, and Fire And Motion by Joel Spolsky. These posts talk about Programmer Productivity, especially the killing productivity patterns. So I though about sharing my positive productivity practices.

Passion

The number one productivity trick is to be passionate by the project(s) you are working on daily. You must believe in them. You must imagine how cool the result will be in one, two, three years from now. In several occasions I took a while to stop and think: hey NDepend (my project) has evolved so much during the last two years. Two years back from now, imagining it would have had all these new features and improvements was science-fiction, today it is reality, a reality that has been delivered to real-world users. How cool!

Patience and Confidence

So not only passion and even love is required but also patience. Measuring all the work achieved during the last X years makes me think that it will keep going up, one feature, one improvement, one bug fix, one line of code, at a time. Each past win is nurturing future wins, and will motivate you to be productive every each hour, because there is no more important (professional) things than that.

Today it seems I lost my whole day fixing a pesky bug, if I wouldn’t have been so dumb I could have fix it in half an hour! No stress, it happened to me tons of time in the past and looking back at all those years I can see it is the way to go. This is confidence.

Getting Started

One central facet of passion for a project, is to have a good idea of where we want to go. Short term (days, week), Mid term (months), Long term (years).

Short term means to me having my code base filled up with prioritized TODO comments, TODO5 being more urgent than TODO4. This sounds like a very rudimentary way of listing tasks but there is a strong advantage with TODOs.

TODOs are located where the coding action must take place. Hence starting working on a TODO eliminate the prior step of finding where to start in code. And the act of getting started (or actually getting not started) is a productivity killer. Hence everything that can possibly help getting started writing code is a productivity asset.

Another advantage of TODOs is that when all TODO(n) have been done, the job is done. No more TODO(n) is a very simple Definition of Done since all tasks surrounding coding (writing tests, code review, validation…) can and must be TODOed.

Getting Focused

Of course at a point, TODOs must be defined and then code must be crawled to find the best possible location where to write them. Typically this happens when starting working on a stuff (a stuff is what Agile and Scrum guys calls a PBI, Product Backlog Item). At this point a PBI gets transformed into (a few or many) prioritized TODOs, depending on the scale of the PBI. It can be a one hour bug fix or a feature that will take 3 months of dev.

There shouldn’t be more than 10 top priority TODOs at a time because one productivity important trick is to get focused on what to do. Hence a feature can be divided in 90 TODO1 and 10 TODO2. Once there is no more TODO2, then we can pickup the 10 next tasks to be done within the 90 TODO1 set. And if the current TODO2 to work on is too coarse, then transform it into 10 TODO3 and so on.

This way every morning you just have to search for TODO(n) in your workspace to instantly know what to do. This way you don’t have to think of what to do today, just get started and stay focused.

Goals

Imagining Mid-term (months) and Long-terms (years) goals is what can nurture passion and then day-to-day productivity. Two TODO lists must be maintained for that. Since NDepend follows Visual Studio releases our sprint duration is around 12 to 18 months. So we have one Mid-term list of what to do for the next major version that will be released in N months from now. The Mid-term list is driven both by ROI (Return Over Investment, the ratio of  Feature impact/ Dev effort) and the User Voice, that offers a good idea of each future feature impact. The same applies to the Long term list, except that this list is not limited by the sprint duration.

Psychology

So far I especially covered some project management and organisation practices that are designed to boost productivity by maintaining the flame of passion intact. But Passion, Patience, Confidence, Getting Started, Getting Focused, defining Goals, are all about psychology. And there are several classic every-day psychology routines that are essential to keep up with high-productivity.

Having a sane and joyful life is of course essential. Personally I need something else than coding in my life. Friends, familly, kids and hobbies. Everyday several hours must be dedicated to something else than coding. One must sleep enough and work at regular hours. You must identify the hours when you are the most focused (typically early morning or late night) and struggle to be able to work during this privileged time. This might sounds obvious to you (and to me) but super-geeky individuals must be reminded that. You just can’t dive into code 14 hours a day and keep up with productivity in the long-term.

I found exercise being the number one creativity boost in my programmer life. Running often is for me a productivity routine. Not only new ideas comes to me gently, they just pops up to my mind, but endurance sport provokes endorphin’s hormones rush that can relieve most pain and stress. Runners actually develop an addiction to this, which is a pretty cool addiction. I consider sport-hours like being part of work-hours. Doing so is pretty practical to never miss a session. Btw I found recently that Alan Turing got many of his super brilliant ideas while running (he got almost qualified for 1948 Olympic marathon).

In addition to sport, I also do some every day meditation, especially mindfulness-based stress reduction (MBSR). This just works to get me more quiet, peaceful and focused. MBSR is a very simple activity that can be practiced several times a day in few minutes sessions. It consists in developing the ability to feel the present moment, by listening to the breath, the body sensation, the environment. The key is to develop the ability to be not emotionally disturbed by the flow of thoughts that constantly comes to the mind. We all know that to develop muscle one must train, but few realizes that brain can and must be trained as well. MBSR and meditation in general, is training to develop brain and cognition capacity.

When it comes to psychology and productivity we often hear of the notion of flow. Being in the flow means being totally focused to the current activity. The conditions for reaching the flow, which is the Saint Graal of the productivity are: being passionate about the activity and having solid skills. We often hear that to be skilled in a domain 10.000 hours of practice are needed. Flow is more for seasoned programmers. Another condition for the flow magic to happen, is to be challenged enough by the task. Flow cannot be reached when doing simple stuffs. The good news is that programming (well) is more often difficult than simple!

Of course avoiding interruption is also an important part when it comes to productivity. There are many interruptions you can control, like treating emails in batch mode twice a day, not arguing on the web, not periodically checking twitter or facebook… This is where the benefits of meditation and sport comes into play, because focus is increased.  There are all non-controllable interruptions, whether it is colleague, meeting, or kids (if you work at home). There is no more alternative than coping with that and be able to get back focused as quickly as possible.

There is this theory of reward that never worked with me. Like if I do code 3 hours in a row then I can go to the beach an hour. This just don’t work for me. I consider the reward to be getting the job done and then if I decided to go to beach an hour today, I will go anyway. Theory of reward maybe work for those that are not passionate by their work. It is your number one professional responsibility to find a job that will passionate you.

I hope sharing my practices of productivity can and will help you getting more productive! Now its time to get back to code (so do I!).

Posted in Productivity | 11 Comments

Agile Software Teams, a Basketball Analogy

basketball-teamWhat makes a great basketball team? Having a great scorer? Having a great defensive presence? Both? Neither?

What makes a great software team?

The other day I was explaining team interactions and dynamics in an agile culture. Being that this was right after the NBA Finals I used the analogy of a basketball team.

In basketball, there is more to building a great team than simply hiring offensive scorers, it’s about creating balance on both ends of the floor and how well the players play together. In many respects, software is very similar.

In basketball it’s not uncommon to label players; Carmelo Anthony is an offensively-minded player. Joakim Noah is a defensive player. Software is similar in that we often have areas of expertise that often lead to labels,  “he’s a database guy”, “she’s a UI/UX person”, or “she’s a javascript guru”. However while players have specialties all players must be “good enough” at the other areas to not create a deficiency in the team.

It would be ludicrous to think that whenever the ball passes mid-court you give it to “the scorer” and expect him to score. Just as ludicrous is the idea that a single person guards the ball on the defensive end, even if that person is the best defensive player.

In 2013-2014 NBA season, the league’s best scorer was Oklahoma City’s Kevin Durant (29.6 points per game) however Oklahoma City averaged over 100 points per game. On average, the best scorer in the league, didn’t score 1/3 of his team’s points!

Why then, do we as software teams often find ourselves defining our work not as what’s effective for the team (shipping software) and instead labeling by functional area? We say, “that’s a designer task” or “that’s for the DBA to do”.

Great basketball teams:

  • Optimize to win games.
  • Win at all costs.
  • Adjust to the team they face.
  • Have players who play well with their teammates.
  • Put team successes ahead of personal accomplishment.
  • Have players who are great at their position.

The point is that having the best offensive or defensive player doesn’t necessarily win championships. What ultimately wins is great team play and adjustment to the team you’re playing. If the key scorer is getting double-teamed, someone else has to step up. If you’re DBA is tackling some gnarly “DBA stuff” and some other “DBA work” needs to get done, perhaps you need to step up and help out. Sure, you aren’t as good of a DBA as your DBA, but last I checked it doesn’t matter who scores the points at the end of the game – two points from Hasheem Thabeet counts the same as two points from Kevin Durant.

Software is the same way, great software teams optimize to deliver software, regardless of who did what tasks. Yes, specialization is important, however it’s the use of the specialization in concert with others on the team that leads to winning.

Whether you’re the scorer on the team, the backup person, or the defensive specialist, I would encourage you to not only learn your position well, but be well rounded enough to help your team win in any situation.

Posted in Agile | Tagged , | 4 Comments