Share it

Sunday, August 17, 2014

Stretch your mind


The more you know,
the more you realize you know nothing.”
– Socrates

There is a big push on young engineers (and colleges that educate them) to build up a wide variety of popular, currently in-demand skills. More popular technologies, common platforms, more courses and projects give students a better chance to hit every bullet point in job recs. It is favorably considered by recruiters and looks extremely attractive to hiring managers who think they are getting a well-rounded engineer at a recent-graduate salary. In addition, it sounds impressive in casual conversations with peers and professionals alike. 

Unfortunately, breadth often comes at the expense of depth. Mastering depth of understanding fundamentals, theories and concepts that are the foundation of modern technologies takes time, effort and dedication to learning. It also takes a lot of effort to learn to work in technologies that give developer more direct access to underlying systems, and data structures. It takes passion and drive to gain an understanding of how to use any technology well, and to set high standards for one's work.

Those with deeper understanding, and the curiosity to gain that understanding, go on to become better software engineers and architects. While not immediately required by a job rec, knowledge of the underlying concepts is regularly needed to solve tough technical challenges in real life. Familiarity with more difficult concepts and technologies makes it easier to learn the popular and simpler ideas that change many times throughout one's career. It is well-established that ability to learn, to think critically and creatively is trained by pushing the mind out of its comfort zone, studying hard, understanding rather than memorizing.

Popular technologies and skills that are “hot” in the jobs market are designed to be easy to acquire, and to solve a narrow set of common business problems, with the trade off that these technologies may not be well-suited to a wider range of applications. These skills are easy to learn and apply. The difference comes in the speed of learning, the quality of outcomes, and the critical thinking that better engineers bring to the job, together with the technical skills. In a competitive marketplace, those who went through the trouble of gaining the deeper knowledge of computer science fundamentals, software construction, and code craftsmanship will fare better.


Sunday, August 10, 2014

Two are better than one

“If you can't explain it to a six year old, 
you don't understand it yourself.”
― Albert Einstein

Pair programming is uncomfortable, exhausting, and un-ergonomic. With pairing it takes two or more people to do a job of one. It is time-consuming to organize, tiring to participate in, and painstakingly slow to observe. The benefits are non-obvious.

Code reviews are nerve-wrecking, aggravating, and painful. They take enormous amounts of time, bring out the worst attitudes, and spur religious wars on code minutiae. Results are often inconsistent, suggestions are petty, and resulting improvement is invisible.

Yet, there is plenty of evidence that teams that manage through the pain and find the time to pair, to review, to swarm, to mob-program, and to work together using any other technique, do significantly better. Pairing and code reviews contribute greatly to the value being delivered in higher product quality, shorter time to release, and in lower maintenance costs.

It comes down to a simple truth, noted a long time ago:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” - Brian W. Kernighan and P. J. Plauger

 Left to our own devices, we want to be clever. But if we have to explain every turn of logic, every leap of faith, and every tiny assumption to another human, the desire for cleverness retires to the back of our minds, and leaves the center stage for the desire to be understood. This difference alone causes a big improvement in the work that we produce. Readable code has a much better chance of being good code, than code that’s hard to read.

It also means that the person reviewing the code, or being the non-writer in the pair does not have to be a developer, she could be anyone familiar with the product.  Even if that person does not contribute directly to the code, their questions will influence the programmer to write better software.

In the case of two or more developers working together, in addition to producing better code, all involved will be intensely learning from each other. And that’s the best thing that could possibly happen to developers.

[It will also make them tired.  I suggest getting a lot of colorful plastic balls, and investing in the fanciest espresso machine your office can afford.]

Tuesday, July 29, 2014

More Agile smells


"Agile" means many things - there are Agile processes, Agile values, Agile ways of working together as a team.  Becoming truly Agile requires a lot of education, willingness to keep an open mind, and lots of trust within the organization. 

When things are less than perfect, as they usually are, many teams get to experience "an Agile smell". Agile smell, similarly to code smell, is not necessarily a problem by itself, but rather a likely indicator of a serious problem with the team’s implementation of Agile.  

Learn to identify Agile smells, and the problems that may lead to them. Then get busy fixing the problems.

Smells "Our KPIs measure the wrong thing"
  • Team talks about velocity points, rather than discuss stories and value created
  • Members worry about being busy and putting in hours, rather than about producing valuable results
  • The team strives to meet arbitrary deadlines, rather than focus on delivering quality working software
It is tempting to measure the team's success by velocity points archived, hours worked, or hitting deadlines. But velocity points are imaginary and unequal units, that differ from team to team, and even for the same team over time. They are too easy to game. Same with deadlines - deadlines are derived from imperfect estimates, and hitting those deadlines causes loss of quality and team spirit. Hours worked is straight-forward to measure, but has little correlation with value delivered. 

Smells "We are not using our tools well"
  • The information in the tool is treated as the source of higher truth, rather than a starting point for a conversation
  • Fill out the fields by the letter of the rules, rather than store useful information in an easy-to-understand format
  • Use the tool insofar as the process requires it, but are uncurious about better ways a tool can help us improve
Tools are there to serve the team. They help to compile information over time, store details, and offer a choice of presentation layouts. Tools are not there to drive the team's value, do the work of coordinating and facilitating communication, resolve issues. It is OK to tweak the rules imposed over a tool usage, if it helps the team to work smarter. It is not OK to be a servant to the tool, rather than its master. 

Smells "We are not being awesome"
  • Compile excuses why we are not doing a good job, rather than look for a better way to work
  • Look for ways to make Agile process entertaining, rather than focus on the excitement of delivering great software
  • Build Chinese walls between specialties, Agile team members and their responsibilities, rather than work together 
IT and software development is complex and complicated work. Every team that works hard and strives for success is going to make mistakes sometimes - and that's OK. In fact, it is good, because the only way to not make mistakes is to play it safe, aspire to little, and settle for less.

Problems do happen, and it is important to admit and examine what doesn't go well, take responsibility. So that the team can improve, do better in the future, and have fun while doing it.  

This is a second post in the series on Agile smells.  Read the first part here