panelarrow

September 27, 2016
by Winter
0 comments

About Relationships

Very recently a large tech announced layoffs numbering thousands of employees. There seems to be one we’re remembering but it could really be any one of several that have gained attention or maybe it’s a general composite of several that have come up.

Evidently hoping to dampen investor and analyst repercussions the company seemed careful to point out that the layoffs weren’t due to dire financial straits.

Was it due to poor recruiting practices, perhaps the company had made thousands of hiring errors? No, of course, that’s certainly not the story the company seemed to want to tell.

People discussing the layoffs rather seemed eager to point out that the technical skills needed by the company had changed so much in five years that thousands of employees were being shed in order to hire a similar number of employees with newly-desired skills. Many of those employees, by implication, had been recruited within the past five years or so.

We could stop here with a story demonstrative of how intensely and blindingly fast the tech industry is moving. “Yes, the danger must be growing, For the rowers keep on rowing, And they’re certainly not showing, Any signs that they are slowing!” [Fearful screams follow.]

But, where did those thousands of people come from?

They weren’t born with specific trade skills as infants: they learned those trade skills and became engineering employees at a West Coast Tech company. We could probably infer that they’re the crème-de-la-crème of savvy and intelligence. That tech company would probably want us to agree, because they certainly don’t hire B-players and they don’t want competitors, analysts, or investors to think they hire B-players.

This brings us face to face with a question. Can those laid-off employees learn the newly desired trade skills?

One of the answers might be, “No, they’re not bright or flexible enough to learn new viewpoints and new ways of doing things.” Which is quite a statement to make about some of the most savvy, technically proficient, creative, intelligent, and educated people in the world.

But maybe it’s just the common and tragic plight of humanity that we suddenly, dramatically lose capacity for learning; old dogs, new tricks and all that.

Perhaps one of the other plausible answers is, “It’s less expensive and faster to shed those people and get new ones.”

We can see examples of this in other industries and other periods: if a company building wood ships needs carpenters they hire carpenters, and when the company starts building metal ships it lays off the carpenters and hires iron- and steelworkers. The company charges forward, the burden and cost of the change takes place outside the company. (Hence we see development of UI and RI programs.)

Is this approach the right one applicable to our most avant-garde and progressive companies and the tech-industry skills of employees numbering in the thousands? Have tech industry executives and investors made little or no progress beyond the days of wood shipbuilding and unfettered exploitation of natural resources?

We’ve certainly met lots of recruiters who’ve demonstrated a mindset that skills (essentially, trade skills) are not transferable — that’s a Java person, they certainly can’t do Perl scripts — and not a small number of recruiters conducting their search using parameters that were almost insanely narrow. As in “we demand to have a new recruit who knows Knucklehead API 12.3.22b and, in fact, we will flatly and rudely reject any candidate who merely knows Knucklehead API 12.3.22a or 12.3.22c.” Regretfully there are recruiters who behave this way.

How did that candidate come to know API version 12.3.22c? He or she learned it.

Some of this came up in a discussion about the nature of the tech industry in which the word “Transactional” was used to describe some prevailing dispositions in the industry. Out with the thousands of ‘old’ employees from two to five years ago, in with the new thousands.

We’re somehow different in our firm.

In our background we were taught to learn how to learn.

We were taught to analyze and understand and acquire thetradeskills.

And, as if to make us even more different, a Relational approach has been woven into our culture since the beginning:

Develop relationships with clients and other talented people.

Understand our clients’ needs, so we can return to help them over and over.

Be as easy to work with.

Truly serve our clients.

Learn new APIs. Learn new technologies. Integrate great things from multiple sources. Take on new challenges.

Accept new clients from new industries. Cultivate lasting relationships with those who become our clients.

Strive to make our clients better off for having engaged with us.

And draw on breadth of experience, learning ability, skills, and understanding both new and old to develop software that works.

As a practical matter we’ve taken on services that weren’t the most glamorous because we knew they would help our client with delivering their product.

We’ve flexed, we’ve taken new challenges, we’ve worked with clients’ partners around the globe…

we’ve debugged third-party technology without source code and sent recommended fixes back to the vendors…

we’ve joined in with innumerable client design sessions, we’ve integrated with clients’ established methodologies when needed, we’ve reviewed projects in need, and we’ve supported clients with phone calls and digital deliveries on the way out to the tradeshow.

Over the years we’ve consistently been invited to carry roles of trust and responsibility with our clients.

Sometimes it’s not about transactions. Sometimes it’s about relationships.

August 25, 2016
by Winter
0 comments

Cheap Software Development Labor

We’ve been wanting to post about “cheap engineering labor” for some time.

The notion of realizing your product vision with a very small budget is incredibly appealing.

Maybe you believe it’s the only way you can bring the product or service into existence, at all.

There’s a good chance that producing something of value, in other words creative quality or “innovation,” is the true economic engine of your business. Most of the huge successes and market shifts come from this.

The percentage of the company’s budget invested in development tends to multiply dramatically. Yes, marketing is of great importance but the products or services delivered are the power plant of your organization.

This begins to beg the question whether product development is the place to engage in the race to the bottom. For example if your proposition of value or KSF is “cheap development labor” how many of your competitors will also have access to that market?

Arguably even more importantly, since your development tends to become magnified as an economic engine what is it that you want to magnify? What kind of engine do you want?

Another question: if you want to build great products but work hard to minimize upfront costs, why not engage the developers of the great product with a residual? If the product they build is wildly or moderately successful why not share a portion of the rewards with them? It’s hard to argue that this would be inequitable and if asked many developers would probably agree that they’d appreciate a residual benefit.

Seth Godin recently wrote, “The race to the bottom is unforgiving and relentless.” (His full post is here: http://sethgodin.typepad.com/seths_blog/2016/08/in-pursuit-of-cheap.html)

Is this the system you want to create for your products’ developers? Is it the system that you want to find yourself personally enmeshed within?

July 29, 2016
by Winter
0 comments

Refactoring Isn’t Free

It’s great to improve code when you’ve learned more about the problem you’re solving.

Sometimes the end result is so much better, and more fitting, than the point at which we started.

But what if you have experience? What if you have skills and foresight?

Do you put blinders on and write something wrong or incomplete so you can refactor it later?

Task switching costs something. Rewriting code costs something.

Sometimes it’s great to refactor.

Sometimes it’s great to get it right the first time.

It’s satisfying to refactor, but it can also be satisfying to never need to look back on the code you wrote because it just keeps on working how it was meant to work, year after year.

July 20, 2016
by Winter
0 comments

Agile and agility 2016

There’s more than one way to do agile.

By definition, agility is not rigid.

If you have to sit together in a certain room in SF or SJ to develop software, how agile is that?

If you must only communicate while standing or using tribal language, how agile is that?

If you’re unable to collaborate with great, creative people all around the country, how agile is that?

November 26, 2014
by Winter Harbor Software
0 comments

Off-Topic: Thanksgiving Proclamation

At Winter Harbor Software love tech and we love tech development.

By its nature, tech looks to the future and looks to make improvements.  Often the results of new development are exciting and very pleasing.

With so much to attract our attention and do in this moment, have we in contemporary culture taken time to notice and take account of things left behind and maybe even to recognize a few things left behind that ~ on further consideration ~ turn out to have been errors to have set aside, departed from, and forgotten?

Here’s what the President of the United States had to say about Thanksgiving; in this case it was President George Washington writing to the people of the United States:

New York, 3 October 1789

By the President of the United States of America, a Proclamation.

Whereas it is the duty of all Nations to acknowledge the providence of Almighty God, to obey his will, to be grateful for his benefits, and humbly to implore his protection and favor– and whereas both Houses of Congress have by their joint Committee requested me to recommend to the People of the United States a day of public thanksgiving and prayer to be observed by acknowledging with grateful hearts the many signal favors of Almighty God especially by affording them an opportunity peaceably to establish a form of government for their safety and happiness.

Now therefore I do recommend and assign Thursday the 26th day of November next to be devoted by the People of these States to the service of that great and glorious Being, who is the beneficent Author of all the good that was, that is, or that will be– That we may then all unite in rendering unto him our sincere and humble thanks–for his kind care and protection of the People of this Country previous to their becoming a Nation–for the signal and manifold mercies, and the favorable interpositions of his Providence which we experienced in the course and conclusion of the late war–for the great degree of tranquility, union, and plenty, which we have since enjoyed–for the peaceable and rational manner, in which we have been enabled to establish constitutions of government for our safety and happiness, and particularly the national One now lately instituted–for the civil and religious liberty with which we are blessed; and the means we have of acquiring and diffusing useful knowledge; and in general for all the great and various favors which he hath been pleased to confer upon us.

and also that we may then unite in most humbly offering our prayers and supplications to the great Lord and Ruler of Nations and beseech him to pardon our national and other transgressions– to enable us all, whether in public or private stations, to perform our several and relative duties properly and punctually–to render our national government a blessing to all the people, by constantly being a Government of wise, just, and constitutional laws, discreetly and faithfully executed and obeyed–to protect and guide all Sovereigns and Nations (especially such as have shewn kindness unto us) and to bless them with good government, peace, and concord–To promote the knowledge and practice of true religion and virtue, and the encrease of science among them and us–and generally to grant unto all Mankind such a degree of temporal prosperity as he alone knows to be best.

Given under my hand at the City of New York the third day of October in the year of our Lord 1789.

Go: Washington

Now, how different are we today?

Have we become so far removed from these people that such early notions of Thanksgiving are irrelevant to us? Is our essential makeup so different today that the initial origins of Thanksgiving have no retrievable meaning to us, leaving us with things like retail statistics and big-screen TVs as the new definitional elements of the holiday?

Or can we find a connection to those human beings who lived during that time, who read that early Proclamation of Thanksgiving, and who found it relevant to themselves?

Here’s a link to the text from the Library of Congress:

http://memory.loc.gov/ammem/gwhtml/gw004.html

October 28, 2014
by Winter
0 comments

Off-topic: Charging Ports and Software Development

Recently we had a charging port fail on a device.  Again.

We did a bit of research and charging ports seemed to be a common point of failure for the device, and the model that came before it, and seemingly for the model that came before as well.

Our perceptions are now that charging ports have killed more devices in our immediate experience than anything else ~ and have seemingly done so for a decade or more.

So why is this the case? Continue Reading

August 25, 2014
by Winter Harbor Software
0 comments

Cost Overruns Solved! …

We do like fluid, effective software development that’s as lightweight as practical.

So we recently read a couple articles describing the badness of “non-Agile” methodologies that spoke of cost-overruns (with those other methodologies) as one of the central proofs of their badness.

The situation seemed very bleak for other methodologies but it seemed worthwhile to reflect on the estimation approaches on the ‘winning’ side.  The basic ideas involved are these:  at project inception (1) we say we don’t know what we’re going to deliver, and (2) we say we don’t know about the cost.     Continue Reading

August 16, 2014
by Winter Harbor Software
0 comments

Assert ( no_errors_so_far );

Assert() can be used to detect logical programming errors made at the time of authoring the software.  Assert can help quickly uncover blatant and even more-subtle errors, pointing out areas where the software isn’t actually  functioning in the way that was envisioned at the time of writing.  Liberal use of assert() is thought to help improve software quality because, of course, the programmer can rapidly discover and correct such errors when running the program at her desk.

Some languages remove Assert() when a release build is generated, so in the hands of users the software’s behavior would be undefined and probably very undesirable if conditions were actually violated.  With some other languages asserts() remain in the final software; in the hands of users the software will often fail instantly by design if the asserted condition is violated.

The use of assertions during development sounds largely positive up to this point. Continue Reading

July 31, 2014
by Winter Harbor Software
1 Comment

A Reminder that (Partly) “Working Software” isn’t the SOLE Measure of Progress

There’s a very nice sort of practical but minimalist simplicity to the notion that “Working software is the primary measure of progress.”   (Of course a lot of readers recognize that’s a quote from Here.)

How easy it can be to forget, in the heat of the battle, that the word “primary” is included in the phrase.  A lot of professional teams lapse into working as if to omit that word.

Here are three reasons that what’s been labelled a primary measure of progress isn’t the sole measure of progress: Continue Reading

July 28, 2014
by Winter
0 comments

The Legend of the Roast

Most likely you already know of the legend of the delicious, highly regarded family roast recipe that requires cutting off both ends before cooking.

Recently we thought of that story and held it in comparison to the path software development methodologies have taken in their development.

Specific practices, sometimes very rigid ones, make their way in and once established “must be done” for a software development process to be dubbed a “true” implementation of methodology XYZ.

How did these practices come about in the first place?  You might ask that question and discover the motivation proffered in some instances is that the technique worked at a certain time in the past, for a certain group of people, under certain circumstances.   Having, at some moment, been experienced as effective the technique became codified.  Once codified, the practice attained status as the “right” way to do things and it no longer mattered that a diverse range of other practices might work to similar effect, might fit better to particular situations, and might deliver better results.    Continue Reading