Wednesday, September 10, 2014

RIF Notes #30

“Clutter is taking a toll on both morale and productivity. Teresa Amabile of Harvard Business School studied the daily routines of more than 230 people who work on projects that require creativity. As might have been expected, she found that their ability to think creatively fell markedly if their working days were punctuated with meetings. They did far better if left to focus on their projects without interruption for a large chunk of the day, and had to collaborate with no more than one colleague.” —Decluttering the company [The Economist]

Friday, August 1, 2014

eXtreme Programming: Days of future past

Going back, maybe ten years ago, when I first read Kent Becks Extreme Programming I found it compelling. Most of the practices made immediate intuitive sense.  I especially liked the practices:  coding standards, unit testing, refactoring, continuous integration, collective code ownership, code reviews and maintaining a sustainable pace. They are now engrained in the way we operate.  What was appealing about them was that they were directly applicable to the practice of programming.  I could and did begin adopting them in some part as an individual to develop my own development skills, quality and productivity.  There was no need for a formal organizational structure or project management philosophy overhaul required in order to just start doing some of the practices and benefitting from the discipline.  Extreme programming is a methodology as the name implies, for programmers. 

Later, as I became more aware of broader Agile, the myriad of Agile practices felt like watered down versions of XP or at least less concrete.  The Agile manifesto’s vague generalities weren’t prescriptive enough, for me, I never really got it.  If fact, I have seen them used to vindicate code-like hell as being agile.  I was disappointed when XP fell out of favor.

Unsurprisingly, I found the project management aspects of XP less interesting personally.  Nevertheless, those are the aspects that Agile became synonymous with.  Teams that are ‘agile’ more often than not refer to their project process rather than their engineering discipline.  Initially I was intrigued by Scrum.   It appeared to be somewhat prescriptive, albeit around the process rather than the programming .  It had a structure which vague Agile didn’t (which may be true of Lean and Kanban too).  In my experience, however, Scrum tends not to be all that prescriptive and molds to the team rather than the other way around.  While agility is great and desirable, Agile still seems to be all over the place meaning everything and nothing all at once.

When I came across Uncle Bob’s Extreme Programming, a Reflection recently and recalled Martin Fowler’s similar criticism of Flaccid Scrum (Scrum without technical practices), I was encouraged to know that I wasn’t alone in my nostalgia for XP.

I recommend going back, re-familiarizing with XP and reclaiming what was lost.

Monday, July 28, 2014

RIF Notes #29

“Most artists and designers I know would rather work all night than turn in a sub-standard job. It is a universal truth that all artists think they a [sic] frauds and charlatans, and live in constant fear of being exposed. We believe by working harder than anyone else we can evaded [sic] detection. The bean-counters rumbled this centuries ago and have been profitably exploiting this weakness ever since. You don’t have to drive creative folk like most workers. They drive themselves. Just wind ‘em up and let ‘em go.”—Linds Redding

 

Monday, July 21, 2014

RIF Notes #28

“Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens. That these acts are simple doesn’t mean that they are simplistic, and it hardly means that they are easy” – Uncle Bob

Friday, July 11, 2014

RIF Notes #27

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” – Melvin Conway

  • Revisiting Conway's law – “if you want cohesive and decoupled systems, put different teams at work on each of them, so that the communication structures of the teams resemble what you want to achieve with projects…Segregation of responsibilities starts by our own work organization"
  • Software Structure Can Reduce Costs and Time-to-Market – “the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system…the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system…when the structure of the code base significantly impedes the time of subsequent deliveries of the right features, a business’s competitive agility is lost and the Return on Investment on the software goes wobbly”
  • Why Projects Don't Make Sense – Projects with discreet beginning and end dates is challenged.  Acknowledging that software is never done suggests that ‘projects’ are not a good match whereas a standing teams might be better.
  • The Corruption of Agile – Suggesting that the productized and cultish practices of Agile have led it astray.
  • Secrets of Handling Support in an Agile Team – “Reserving capacity is not enough. So the dev team dedicates one developer per iteration for support work. The developer handles all support tasks”
  • Hordes Of Novices – Uncle Bob asks “Do you really get software built faster and better by throwing ever more barely competent bodies at it? Is the software problem really a raw manpower problem? Is coding the same as bricklaying? More bricklayers means more bricks and more coders mean more code; but is more code what we want?”

Thursday, July 10, 2014

RIF Notes #27

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” – Melvin Conway

  • Revisiting Conway's law – “if you want cohesive and decoupled systems, put different teams at work on each of them, so that the communication structures of the teams resemble what you want to achieve with projects…Segregation of responsibilities starts by our own work organization"
  • Software Structure Can Reduce Costs and Time-to-Market – “the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system…the structure of software largely determines how long it takes and how expensive it is to develop, test, extend, and maintain a software system…when the structure of the code base significantly impedes the time of subsequent deliveries of the right features, a business’s competitive agility is lost and the Return on Investment on the software goes wobbly”
  • Why Projects Don't Make Sense – Projects with discreet beginning and end dates is challenged.  Acknowledging that software is never done suggests that ‘projects’ are not a good match whereas a standing teams might be better.
  • The Corruption of Agile – Suggesting that the productized and cultish practices of Agile have led it astray.
  • Secrets of Handling Support in an Agile Team – “Reserving capacity is not enough. So the dev team dedicates one developer per iteration for support work. The developer handles all support tasks”
  • Hordes Of Novices – Uncle Bob asks “Do you really get software built faster and better by throwing ever more barely competent bodies at it? Is the software problem really a raw manpower problem? Is coding the same as bricklaying? More bricklayers means more bricks and more coders mean more code; but is more code what we want?”

Monday, June 23, 2014

RIF Notes #26

“Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens. That these acts are simple doesn’t mean that they are simplistic, and it hardly means that they are easy” – Uncle Bob

 

  1. What's culture got to do with it – Looks like Cooper is offering a Culture Master class. This training aims to help people intentionally approach their team or organizational culture.
  2. An Overview of Project Katana - Whereas both the OWIN specification and Owin.dll are community owned and community run open source efforts, the Katana project represents the set of OWIN components that, while still open source, are built and released by Microsoft. These components include both infrastructure components, such as hosts and servers, as well as functional components, such as authentication components and bindings to frameworks such as SignalR and  ASP.NET Web API.
  3. Microsoft claims Azure now used by half of the Fortune 500
  4. Duplicate Finder, Part of ReSharper Command Line Tools
  5. Running Javascript inside PowerShell with PowerShellJS
  6. Introducing Windows Azure WebJobs -  there's not yet been a good solution under web sites for doing regular jobs and batch work in the background. Now Azure Web Sites support a thing  called "Azure WebJobs" to solve this problem simply.
  7. On The Coexistence of ASP.NET MVC and WebAPI
  8. CORS Support in ASP.NET Web API 2- Cross-origin resource sharing (CORS) is a World Wide Web Consortium (W3C) specification (commonly considered part of HTML5) that lets JavaScript overcome the same-origin policy security restriction imposed by browsers
  9. SSRS Reports as a Data Source in Excel 2013 – “I became intrigued by the possibility of using an SSRS report directly as a data source for Excel”
  10. Dev tools essential for building the modern web.