How Project Managers May Facilitate Software Developers

Over at Frederico Tomassetti's blog, he discusses how PMs and developers should communicate business priorities and consider technical priorities as part of the process of improving how these two professions interact, with the goal of improving a work product.

As a student of the Toyota Method, I've often looked to industrial process improvement for ideas on how to better manage teams, specifically around technology projects. But software development is not about 'manufacturing' an application. Modern management comes from the industrial revolution, and the idea of increasing production by adding labor, machines, etc. Software, to me, is still very much an artisan craft. Understanding user requirements to be functional is key -- the more detailed the requirements, the more time developers spend figuring out how to implement. Beyond this, some problems require the abstract thinking of a software engineer or architect, not just the assembly of blocks of code.

I have found that unrealistic schedules are the major cause of project failure. In the 1980s, Frederick Brooks noted in “The Mythical Manmonth” that adding staff to a project that was behind schedule only helped it to be further behind schedule. When estimating a technology project, two key components are difficult to assess: the complexity of requirements; and, the productivity levels (outputs) of the development team.

My solution is to track progress, and that means capturing data (metrics). But if information is not collected or collected so inconsistently, comparisons and trends are impossible. If no data is being collected, management has not required it. If collected inconsistently, KPIs have not been established and enforced, or standards are burdensome so they are circumvented. Productivity measurement and project management are powerful tools for planning, overseeing, and evaluating software development and maintenance projects -- the PM should guide the ship, so developers can pull the oars together.

Read more here...

Take a Cloud Computing Quiz

Many times customers ask me, "I am scared of the cloud. It is too dangerous to keep my precious data in." My response: probably not for you, then, if you think that. I like to quiz potential cloud computing aficionados, for example, asking, what is private cloud? Is it a gated community on the internet, or a cloud architecture built within an enterprise data center? What can you do with a cloud-based computing environment? Have no worries about running out of storage, immediate access to computing resources, and pay only for what your apps use?

Answering questions like those help focus customers on the advantages of cloud computing. Confronting the myths about the Cloud can be challenging. Read more here...

Why Taxis Need Uber...

The so-called "gig economy" is picking up steam... freelancers replacing full-time staff, companies focus on profits and shareholder value rather than hiring new permanent employees. With this type of work arrangement, geographically diffuse and independent workers are paid piecemeal for completing tasks -- facilitated by the connections from internet-based apps.

Amazon of course has Mechanical Turk, the original "piece work over the internet" freelancers platform. Another Amazon effort riffs on Uber: package delivery. Mechanical Turk is a platform where workers complete microtasks (such as transcribing, proofreading or answering surveys) for, many times, cents on the dollar. These internet denizens work on their own time and can pick up gigs on-demand.

But with the competition to taxis, Uber is really reshaping how the freelance economy works. People forget, in the U.S., most taxi companies retain drivers as 'contractors,' and require the drivers to pay for fuel, maintenance, etc. Regulation has come about to make a partially-public service (shared rides) more consumer-friendly (taxi meters, inspections, licensing). Tim O'Reilly says,

Regulation is not a good in itself. It is a means of achieving public goods. And so far, it is pretty clear that Uber and Lyft (and in particular, the competition between them) are improving the transportation options in American cities. Regulators should be using the opportunity to revisit the old way of doing things rather than trying to make the new conform to outdated rules that no longer serve their purpose...

Read more...

Will Über and Others Make Autonomous Cars Ubiquitous?

Of course they will! That headline is sort of silly -- as we read over at BuzzFeed, "There’s a lot of skepticism about self-driving cars. About how successful they’ll be, about whether people will really want to use them, about whether they’re safe. But this is what you should know about autonomous vehicles: They are coming. Inevitably. Inexorably. Coming."

Further on...

The first time I rode in a fully autonomous car, what really impressed me was when the car saw something that I could not. As I rode down a residential street in Mountain View, the car slowed, for no apparent reason. Yet in the front seat, a laptop showed everything the car could “see.” And up ahead, there was a man, in the street, standing behind a double-parked vehicle. He was concealed from my eyes, but the car detected him. And it slowed down, anticipating that he might step out unexpectedly.

We read at Forbes that Google’s $258M investment in Uber shows it is serious about commercializing the Google Car. Even without car sharing, driverless cars will deliver tremendous social and economic benefits. Every year, more than 1.3 million people die in car accidents worldwide, and more than 50 million are seriously injured. In the US alone, more than 34 thousand die and 2.2 million are injured in over 5 million accidents. 90% of these accidents are caused by human error. Google has declared its intention to reduce accidents by 90% using driverless vehicle technology. Volvo is on a mission to eliminate all deaths and injuries in its cars by 2020.

Microservices - decomposition writ small

Building robust enterprise solutions requires thinking differently. For many, service oriented architecture is the way to go. But recently, the influx of microservices challenges the idea that there's only one way to skin the proverbial Information Technology cat. As Torsten Winterberg puts it, “Microservices are the kind of SOA we have been talking about for the last decade. Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths. Classic SOA is more platform driven, so microservices offer more choices in all dimensions.”

I have always been of the mind that service oriented architecture (SOA) represents an architectural pattern for software design where application components provide services to other components via a communications protocol, typically over the internetwork. Today, many embrace the idea of micro services -- in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. Now, this seems to be splitting hairs, but in practice the concept of microservices might be hard to distinguish from SOA principles. Think of it this way: With SOA, one could write business logic to query a dataset to GetPaymentsAndCustomerInformationAndPurchaseHistoryDataAPI and AuthenticateUsersAPI. The approach from a microservices pattern would simply be to deconstruct those two APIs into much smaller units (GetCustomer; SubmitPassword). The net result is of course the same transactional processing and data traversing the wire, but in smaller increments. And new uses for the multiple APIs could be found, perhaps.

Perhaps the biggest gains in taking a microservices approach resides in cloud-deployed applications. Monolithic applications are sometimes wholesale moved to the cloud, but every time a rev is made, even to a small part of the app, the entire solution to be rebuilt, tested and deployed. With the alternative, smaller units are revised with agility, and downtime is reduced or eliminated.