December 2014 Newsletter
The job of leadership is to foster alignment and enthusiasm toward the right goal. –Ev Williams
Progress lies not in enhancing what is, but in advancing toward what will be. –Khalil Gibran
Just start. Otherwise, the desire to be best can get in the way of getting better. –Tom & David Kelley, Creative Confidence
Culture, leadership and employee engagement are the essentials for great customer experience. – Steve Cannon, President & CEO of Mercedes-Benz USA
A proud man is always looking down on things and people; and as long as you are looking down, you cannot see something that is above you. –C. S. Lewis
As a programmer you read more code than you write. Keep it readable, commented, consistent and explicit. –Sindre Sorhus
What good is it being chaste, or merciful or honest only when it’s easy? It’s when you are afraid that it is hardest, as they say, to choose the harder right over the easier wrong. –Winston Churchill
This article does a good job of dispelling the myth that missed deadlines
are (primarily) the fault of the development team. The author points out that the most common
reasons for a failed project schedule are unclear requirements, changing
requirements, and context switching. He
goes on to make some suggestions for how to address these issues in your
process.
https://sprint.ly/blog/your-developers-arent-slow/
As almost a counterpoint to the article above, here we have an argument
for why you should slow down when you a programming. Borrowing ideas from the slow food movement,
the author suggests that part of the problems that we have with programming is
too much emphasis on technology (I call it the “magpie syndrome”) and not
enough focus on who we build applications for.
https://ventrellathing.wordpress.com/2013/06/18/the-case-for-slow-programming/
This comprehensive article looks at how the idea of basing the practice
of software development on other engineering disciplines has failed and how the
software craftsmanship movement has replaced it and how the methods are now
being underpinned by good foundational theory.
http://queue.acm.org/detail.cfm?id=2693160
Whether you are just getting started with agile or it’s old hat, one
problem that seems common is the suitable level of granularity for user
stories. It’s a delicate balancing act
between too much detail and not enough, especially when it comes to estimation
and measuring progress. Here are three
tips for assessing story size and breaking them down appropriately.
http://www.jrothman.com/mpd/agile/2014/11/three-alternatives-for-making-smaller-stories/
In this newsletter, we frequently feature articles about how developers
can do a better job at “design”. In this
article, the author presents the unique perspective that the “user first”
mindset of designers is also a good approach to the overall project management
effort, because it highlights the importance of business value in all
decisions.
Too often, I believe that we think of agile as a “no-documentation”
process. This seems especially true of
having a general specification (or perhaps what might be called a “vision
document”) which outlines the business value proposition of the work and
provides some basic boundaries for scope.
This article does a good job of presenting how to create and maintain
such documentation through the life of an agile project.
This is a very insightful article about why developers typically don’t
want to interact with business users/stakeholders. The author claims that it’s the perception
that business users don’t treat them as peers, but as subordinates.
Industry heavyweights Erik
Meijer and Vikram Kapoor suggest that, regardless
of what business you are in, your company is a software company. Their evidence for that claim is based on the
observation that the fastest growing companies are ones which have successfully
harnessed innovation in their software systems.
In particular, such companies are able to use information provided by
their systems to make good, timely decisions.
https://queue.acm.org/detail.cfm?id=2685692
While I certainly don’t expect this article to end the strong-typing versus weak-typing debate, it is interesting that the choice does have a positive impact on testability and apparently code quality. Of course, it’s probably difficult to account for the inherent capabilities of developers who work in strongly-typed languages versus those that don’t, so you are reminded that correlation does not imply causality.
http://danluu.com/empirical-pl/
While this article has ‘QA’ in the title, it’s really an article for everyone who works in the software development process. The author emphasizes that building (remember that you usually can’t test it in!) quality into your application or system is about each individual’s mindset and the collective culture of your organization, especially around attention to detail and advocating for the customer.
http://randsinrepose.com/archives/the-qa-mindset/
A number of software testers are pushing back on the suggested new ISO 29119 standard for software testing. Most of the criticism comes from the context-driven community says that it emphasizes process and documentation over the objectives of testing in finding problems and helping management assess risk.
This is an interesting and detailed look at what testers do at Finnish game developer Frozenbyte, known for the Trine series of games. How does this compare with your daily routine as a tester?
http://www.frozenbyte.com/2014/09/a-day-in-the-life-of-frozenbyte-qa/
While this article is somewhat of a rant (and I try to stay from those in this newsletter!), it has some very relevant points with respect to how to compensate for limited resources on projects and the necessity of defensive coding and having a set of solid, well-maintained tests for your code, especially for APIs and tools that other developers use and rely on.
http://danluu.com/everything-is-broken/
Since most of us no longer celebrate the Twelve Days of Christmas, perhaps you can make a new year’s resolution to consider this list of a dozen best practices for developing web applications (a.k.a. software-as-a-service or SaaS). And most of these principles apply just as much to any type of application implementation.
You’ve probably heard about Docker (not the pants!), even if you haven’t used it… Yet. But it’s likely you’ll have a use for it eventually for either development or in a production environment, so why not watch this short (~15 minutes) screen cast (with transcript and links!) that introduces the concepts behind it and use cases, including a simple example of using it with Vagrant.
https://sysadmincasts.com/episodes/31-introduction-to-docker
While I don’t think that you are likely to use such a formula in your code (since it’s probably more efficient just to build a look-up table), this is an interesting view on how you can heuristically go about solving a programming problem.
http://cmcenroe.me/2014/12/05/days-in-month-formula.html
Almost every application today uses a database of some sort or another, whether it’s a lightweight relational database, like SQLite, or one of the many flavors of NoSQL platforms. This well-structured and excellently curated list of articles will help you understand (and appreciate) the history and background of the principles of databases.
https://github.com/rxin/db-readings
REST is the de facto technique for web services today. However, with the loose-coupling of REST (which is a good thing overall), it’s easy to get sloppy with your API. Here are some brief, but valuable tips for creating a solid, easy-to-use API with examples of each item.
Frequently, we note that you don’t have to be a graphic designer to develop appealing UIs for your application. This two-part article proves the point by clearly explaining each of the principles and giving plenty of examples, with a focus on mobile and responsive design.
https://medium.com/@erikdkennedy/7-rules-for-creating-gorgeous-ui-part-1-559d4e805cda
https://medium.com/@erikdkennedy/7-rules-for-creating-gorgeous-ui-part-2-430de537ba96
All of us are familiar with the Seven Wonders of the Ancient World and probably with their counterparts of the “modern world”. This series (contrary to the title!) presents the Slate editors’ picks for seven developments of the technology era (“post-modern era”?) that have had the most significant impact on our world.
As organizations get larger (and, in my experience, the longer your tenure at one place!), the demands on your time increase as well. This developer makes a good case for why it’s not only necessary, but appropriate, for you to develop the skill of telling people “No” (or “Not right now”) to ensure that you focus on the things that are important.
http://boz.com/articles/say-no.html
Perhaps it’s just an informal chat that you strike up with a coworker in the break room. Or maybe it’s a formal discussion with the boss. Either way, most of us struggle with the best way to part ways when the conversation is over. Here are some evidence-based tips for how to do it appropriately.
http://www.fastcodesign.com/3038950/evidence/the-science-of-politely-ending-a-conversation
We often throw around terms like goals, strategy, and tactics, but do we really know what they mean contextually? This brief article gives a nice explanation of them and how they are related in the context of implementing a change.
http://sethgodin.typepad.com/seths_blog/2014/12/goals-strategy-and-tactics-for-change.html
Most of you probably remember the classic scene in Return of the Jedi where Luke scolds the Emperor for his pride with the statement, “Your overconfidence is your weakness.” This article confirms that we are more likely to make “rookie mistakes” when we become skilled and then lazy by resting on our laurels.
http://riskology.co/lazy-expert-syndrome/
Wondering if streaming media results in a lot of traffic on the Internet? Well, while BitTorrent is still the reigning king (by a long ways!), Netflix alone accounts for almost 10% of the upstream traffic ahead of HTTP.
This article serves as a cautionary tale about how most “technology wars” are usually have very little to do with the technology itself and more about business and economics. When we consider the technical options that we have available, we must always remember that our fundamental job is to deliver business value, not the most technologically sound solution.
http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt
Mermaid is a small JavaScript library/toolkit for creating simple diagrams, such as flowcharts, using Markdown-like syntax. You can easily embed your diagrams in wikis and other documents, which makes it useful for code diagrams and the like.
https://github.com/knsv/mermaid
If you use the handy Vagrant virtualization platform for application development, Vagrant Manager is a nifty little extension that allows you to manage (start, stop, bounce, etc.) your boxes from the system tray (Windows) or menu bar (Mac OS X). Likewise, it will give you an at-a-glance view of the status of your boxes.
Comparing files is one of the most common tasks in programming and web design. The standard diff tool works fine, but icdiff brings it to a whole new level by providing side-by-side comparisons and colorful highlighting of differences. It works anywhere that Python runs.
Think you’ve got what it takes to be a venture capitalist? Sandhill Exchange bills itself as a fantasy venture capital game. Invest your virtual assets in new companies and technologies and then compare your acumen with real investors.
If you are of a certain age, you will probably remember those maddening (at least to me!) posters that had a bunch of colored dots concealing an image called Magic Eye. This browser-based tool lets you create your own by drawing the image to hide! And you can even configure some of the parameters.
http://peeinears.github.io/MagicEye.js/