February 2014 Newsletter
When you blame others, you give up your power to change. –Dr. Robert Anthony
You can only find truth with logic if you have already found truth without it. –G. K. Chesterton
The height of your accomplishments will equal the depth of your convictions. –William F. Scholavino
If the fool would persist in his folly he would become wise. –William Blake, The Marriage of Heaven and Hell
If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate. On the other hand, if expected value were only 10 percent greater than expected cost, lateness would be a disaster. Yes it would be a disaster, but instead of obsessing over “What’s the matter with those software folks who didn’t deliver on the schedule we gave them?” we need to ask instead “Why did we ever kick off a project with such marginal expected value?” The louder the complaints about project lateness, the more likely it is that the project set out to deliver marginal value and was therefore kicked off under the false premise that it could be completed on the cheap. What’s really wrong with us software folks is that we’re continually beating ourselves up for something that’s somebody else’s fault. –Tom DeMarco, All Late Projects Are The Same
The machine does not isolate man from the great problems of nature but plunges him more deeply into them. –Antoine De Saint-Exupery
You never know what worse luck your bad luck has saved you from. –Cormac McCarthy, No Country for Old Men
Whether you do refactoring explicitly or just as part of the normal process of code clean-up, this article provides some useful advice for effective practices with respect to the process of doing refactoring.
Anyone who has worked in IT for very long has probably been involved in the implementation of an application from a third-party vendor, so-called “enterprise software”. And a common result was less than a shining success story. The main reason for these problems is not a big secret: The people who bought the software package are not the people who will use it.
Anyone who has worked on software development projects is familiar with the crunch mode just before release. This is a very elegant argument for why these “superhero” actions are bad for both the development team and, just as importantly, the customer.
One of the things that we usually learn early in programming is to keep our functions small. But many teams no one explains the reason behind this. This excellent article provides some good reasoning, as well as how to decide to refactor and how to avoid the problem to begin with.
Even after 50+ years and the rise of the GUI, the humble text editor (usually Vim or Emacs) is still the choice of most developers. This author believes that since programming still (and will continue to for a while!) involves manipulation of text, even to implement GUIs, the era of the text editor will persist. What do you think?
While we all know that no methodology or process is one-size-fits-all, this author explains why they moved from Scrum to Kanban. The main motivation for them was that Scrum has an implicit assumption (in their view) that you are good at estimating and most teams struggle in this area.
When it comes right down to it, almost all that executives and senior management want to know about a project is how much it will cost and when it will be done. Historically, IT has done a poor job in estimating either of these. This article discusses a possible approach for making reasonable commitments even with many unknowns about a project.
Most of us are familiar with the standard programming design patterns, especially the so-called “Gang of Four” patterns. But do people actually use them in practice and, if so, are they valuable? This interesting research pulls back the covers on these and other questions.
In my experience, the transition of IT organizations to agile methodologies has often left architecture out in the cold. And this is not a good thing. This article recommends that architecture be put back into its appropriate place and, at the same time, that the objective of architecture (which, in my view, is to make sure that development teams understand the “big picture” goals and objectives) is clearly understood and implemented (perhaps a simple sketch will do!) so that the objective is achieved without extra overhead. And your architecture approach should be to focus on the critical areas, which are frequently the pain points.
Venture capitalist Ben Horowitz explains that he believes the biggest factor that makes an organization successful are those that have the attitude that they will accomplish their goals and work hard to see that happen. His keenest observation is that the only people that naysayers hurt are themselves. It’s probably time to read Teddy Roosevelt’s brilliant exhortation about “The Man in the Arena” (and all of his “Citizenship in a Republic” speech).
What do you think is the most important skill for a software tester? My conventional answer is “inquisitiveness”. In a similar vein, the testing manager at Taxware says that creativity is paramount for testers.
One of the concepts behind agile development is the breaking down of the walls between traditional development roles. This article provides a look at how “non-testers” (you know, programmers, designers, scrum masters, project managers, etc.) can and should be involved in the testing process for your application.
If you are new to testing, you may have heard about exploratory testing, but aren’t sure what it’s good for. This article gives a very good discussion about how you can use it to improve your skills as a tester.
If one of your resolutions for 2014 is improving your skills, you might consider learning mobile application test automation. One study found that half of mobile application developers don’t have time to sufficiently test their programs before release.
At least until the NSA gets its quantum computer, AES256 is the most secure of the widely-implemented encryption standards. This brief overview will give you the background about it.
Even though REST has been around for quite a while, it’s really only come into its own in the past few years. It’s almost imperative for any site to have a REST API now. This article gives some best practices for developing a good REST API.
While you are unlikely to have a job programming in Lisp, there seems to be a consensus that learning and understanding Lisp helps you become a better programmer regardless of language. This site takes the well-known and highly regarded SICP text and adds interactivity by allowing you to edit and run the examples alongside the text.
Do you have a friend, or perhaps know a child, who has expressed interest in programming, but wants to know a little more about what it is? This 7-part series from Microsoft is intended as a reference for their Software Development Fundamentals certification exam, but it gives a nice overview of the basic concepts, including some hands-on lessons (using Microsoft tools, of course!). Each video lesson is ~30 minutes and the last part has a nice discussion about whether programming and/or web development is a good career choice for you.
Under times of stress and impending deadlines, it can be easy to lose your sense of humor. This article shows that we have scientific evidence that using humor properly is imperative for building a successful team.
So, by now, many of us have already abandoned our resolutions for the new year. But, as we frequently note in this newsletter, your career and personal development are mainly your responsibility. So here are some great tips (“resolutions”, if you like!) for improving your skills this year that everyone can keep!
At one time or another, many of us have probably had an “identity crisis” with respect to what to call ourselves. This interesting article looks at the skills and traits of the various technology workers. The author claims that the “sweet spot” is what he terms as a “developer”.
Most technical workers appreciate supervisors who have done their time in the trenches and know what development is about. This developer-manager (who happens to be the CTO of MongoDB) suggests that technical managers (and above!) should spend about 1/3 of their time actually coding. Personally, this seems a bit high, but I think perhaps spending several hours a week with the code hands-on, which may include testing, code reviews, and the like, is good. What do you think?
Even though we’re already a little ways into the year, you may still be thinking about what goals you want to set for this year (and perhaps beyond!). This author says that goals are ineffective, because they do not provide the context or means for how to accomplish them. He says that instead you need to develop a system for achieving your objective. Seems like a very astute observation!
Well, this is a far cry from the last 5+ years of economic difficulty! Based on a recent survey, Dice found that 5 of the 12 most tight labor markets for technology are in the Midwest, including St. Louis and Little Rock.
At its core, programming, while certainly a technology-based discipline, is really a creative endeavor. As a programmer/developer, you are trying to create something (the program!) that doesn’t exist (yet!) to accomplish some task. And creative work requires extended periods of concentration without distraction, context-switching, or interruption. This article gives some good advice for how to help others understand the need to spend dedicated time on the programming tasks by explaining it in terms of cost (financial and otherwise) which is likely to be very important to them.
As technology workers, we are part of the process of introducing new, often disruptive, technologies in our workplaces. In this article, The Economist looks at how the technologies of today will shape workplaces in both the near- and medium-term future, with some speculating that it will result in economic stagnation.
All of know that the growth of traffic on the Internet is still growing at an enormous rate. But did you know that currently there is one Internet-enabled device for each person on the planet, but there will be twice as many by next year? Or that it would take you 5 years to watch all of the video transferred over the Internet each second?
With all of the turmoil over security and privacy generated by the Edward Snowden leaks in 2013 (and other problems), it’s hard to know what the future of the Internet will be. The “inventors” of the Internet, Vint Cerf and Bob Kahn, are interviewed about what they see as the future.
In 2013, Skype saw growth of 36% in Skype-to-Skype international calls to a total of 214 billion minutes. This is 40% of the total traditional telecom international voice traffic for the year.
In a lot of cases, a simple screen shot suffices to show a problem or application behavior. And, usually, a full-fledged screen-recording tool is overkill. But if you need to do simple isolated screen recordings that are easy to share, then check out LICEcap. It records a framed area of the screen (you can adjust the framed area during recording!) and saves the output to a standard animated GIF file (or their highly-compressed proprietary LCP format). Just paste the file in an e-mail and recipient can view in most any web browser or graphic viewer.
One of the most frequent actions that I do in Windows Explorer with the context (right-click) menu is adding a new folder. It can be annoying (and time-consuming!) to wait for the “New” sub-menu to display and then to scroll to the “Folder” option. NewFolderEx simply adds a “New Folder” item directly to main context menu in Windows Explorer to simplify adding folders.
Vagrant is an awesome tool for creating and managing virtual environments for your development process. But its configuration syntax is quite arcane. Rove.io helps you create a Vagrant configuration file for common options, such as database platforms, programming languages, and version control. (If you mainly work with PHP, I highly recommend PuPHPet, which has many more configuration options, but is limited in terms of platform choices.)
Every year it’s the same story: By the end of the year (or even mid-year!), when I sit down to write my comments for my annual review, I can hardly remember what I did. I remember being busy, but can’t think of many specific examples. This year, I’m going to try year.sh. It’s a simply shell script that you use with Git to quickly document salient accomplishments. It can list your accomplishments and even has some basic editing functions. (In Windows, you can run it in the Git Bash shell.)
Mind maps are an excellent tool for both documentation and problem solving. MindMup is an intuitive, free online mind mapping tool. It has a complete set of keyboard shortcuts for quick editing. And you can save your map as a file, to browser local storage, or even Google Drive. Likewise, you can export maps to a variety of formats, including PDF, PNG, and HTML, for sharing or use in other applications.
Do you ever run a command at the Windows Command Prompt and then have to select the content to copy it? Here’s an easier way! Just pipe the output of the command to the Clipboard like this:
command | clip
For example, to send the output of tracert, you’d run
tracert google.com | clip
Source Code in Television and Films
Those of us who work with computers frequently often chuckle at how Hollywood portrays systems. This blog shows screen shots of computers from TV and movies with a note about the programming language used. And you even learn that one of them even has a bug and that Iron Man is controlled by Lego RCX code. J
If you came of age in the 1980s (or even maybe the early 1990s!) with the pre-Macintosh Apple II, you no doubt remember Robot Odyssey. It was a game that was so fun that it hid the fact that you were learning programming skills. This excellent essay by a programmer tells about how it inspired him. And perhaps it might inspire a young person you know, as well. Or maybe you just want to play a clone of the original game.
Even if you don’t have much more than a passing fancy for mechanical gear, this site is extremely cool. It has incredible animations of over a dozen engine times with explanations of each cycle for a particular engine.
This year marks the centennial of the start of the Great War (World War 1). Read these diaries from British soldiers on the front line of the conflict. They are both heart-wrenching and eye-opening.