For Those Entering Tech.

algorithms fearI had a recent Skype conversation with someone working at a company that I had done some contract work for. I suppose I went in knowing how it would go and for a bit of closure – it was the same old story. Contractor does work for a company, contractor does what was required faster than company expected in the hope of a more permanent position, company ends contract.

Someone messaged me on LinkedIn, looking for sage advice because of what I had written – thinking me sage when I am only greying, thinking me wise because I’m good with a keyboard. And all I could come up with this was:

It was a salt trap. 

One of the good things about taking myself out of the job market is to write, unrestrained, about career-limiting topics – mainly because the career is over because I decided not to continue falling for the salt trap. I decided it was time to shift my future, so I did and I have no regrets – though the adjustments are still happening.

My experience in the Software Engineering market spans pre-Internet to last year (and whatever I fiddle with these days). I’ve only worked for one true multinational, and I’ve done work or worked for companies that have disappeared in the churning of economies. Most of the code I wrote – if I called it ‘my code’, intellectual property lawyers would cringe – is not in use. I’m almost sure of it. Contributions to projects deceased.

Sisyphus on a conveyor belt rolling against him. And the project managers and upper management keep singing,  “Keep pushing, folks.” 

In this, I suspect, I am not alone – I suspect that people around my age in the industry have done their time in the Code Mines of places long forgotten. We’ve been through bad economies, through tech bubbles and their inadvertent falls. We’ve seen the rise and fall of languages and frameworks, of business practices that range from asinine to outrageously lucky – rarely solid.

So what is this all about? Oddly enough, it’s about fear. It’s the rare tech company that is built to last; most seem to be built to get money in a tech ponzi scheme – from venture capital to buyouts. The big picture is lost, leaving some really smart people writing some really good code that will not last, that isn’t intended to last, that is meant to get someone else to their own version of success.

Disgruntled? You bet, though I have taken the Path to Gruntlement. There are so many young ones in technology trying to get their street cred, fluffing their resumes – is it appropriate to fluff your own professional persona? – competing against each other like crabs in a barrel, necessarily antagonistic in a market that would do better with more collaboration. Or is it the natural antagonism of tech people? It’s hard to tell.

So my advice to those entering the market is that the market is not the few tech companies you are unlikely to work for, it’s the churning primordial ooze of failures that makes the market – and you will, at the least, have to weather that – if you’re lucky, if you’ve had a good start or get the right opportunities, know that these can be fleeting and that it’s easy to slide back into the ooze. Accept that it’s not going to happen the way you want – or the way that anyone else does, anyway.

Learn and move before they disappear.

Find recruiters that don’t suck. If you’re getting cold called at work by recruiters, block their numbers. Professionals would send you an email first.

Find managers that don’t suck. I could write a book about that. Maybe I should.

And keep pushing until you tire of it – and recognize when you are tired before your body figures it out.

Identifying The End of the SDLC (2015)

Killer QueenDeath is not the opposite of life, but a part of it.Haruki Murakami

Software projects die. Call it retirement, ‘end’, whatever you wish – they die. In a perfect world, this is planned for – expected – understood. In the real world, many software projects were never established formally and have to be brought, kicking and screaming, to the table for hard decisions to be made.

Some software projects continue living out of some perverse masochistic need to keep them living – but they’re dead but for the efforts of those keeping them alive. Sometimes it’s necessary to admit that the software is beyond repair if only for a business to stop losing money and by that time a company is already deep in the quagmire in the project.

This, of course, is written mainly for businesses with software projects. Some are defined as software projects and some are not – I’ve encountered quite a few software projects over the decades that started off with the question, “Wouldn’t it be nice, if?”, and evolved based on that – a spiral model of requirements that doesn’t necessarily translate into a spiral model of development. While I have worked on successful projects and the world celebrates such successes, it’s the failures that create best practices and other rules of things-not-to-do.

A best practice should be planning for the end of the software life cycle throughout the life of a project – including planning the project. That’s part of any solid software development plan – a living document of a project. that exists in one form of another, be it in one person’s head or many people’s head. The latter creates the conflicts in a project that putting the document in written form so necessary. If this development plan doesn’t exist, identifying the end of the software project – it’s death – is almost impossible.

There are a lot of my fellow professionals out there who know about the software development life cycle to varying degrees of intimacy. In theory, we all want to begin things properly but we never discuss the end too much – and, oddly, the end is typically what employs the most software developers outside of relatively few software companies – the fact that when the software project was started no one planned for planning for it’s death. “Just one more change”, someone will say in consternation, “and we’ll move on to the next evolution because…. <insert your phrase of choice here>“.

It’s rarely blatant to management, and depending on what motivates the software developers, they may be immune to the pungent smell of necrosis if only for fear of not finding employment in a job market that is less than friendly.

For any technology to be sustainable, the economy surrounding it must be sustainable. Identifying the end of a software project requires attention to new technology adaptation both inside and outside of the user demographic as well as an actual interest in what the user demographic wants (will pay for) and needs (what it cannot do without).

The key to knowing when a project is dead is assessing whether the project will make more money than is being spent on it. I’ve worked on projects decades old that were still quite profitable and I’ve worked on projects a year old that were money pits – and a business that keeps throwing money into the money pit is unlikely to remain in business longer than their capital permits.

So how can you tell whether a software project is necrotic? There are a lot of very subjective things that have to be considered, such as the business direction and vision of the future as glimpsed by management – and they color the items listed below as well. In the end, it’s up to management.

There are also very, very simple things that will tell you whether it’s time to break out the candles for the project and will help assess whether any software project is in it’s death throes – or toxicly necrotic for the business.

  • Spending More On The Project Than It Brings In: While this is true of most startup software, the subjective aspects of vision and business direction overshadow it – and sometimes they continue to do so longer than they should. A software project should have a budget. Your company can fight over what is considered an expense and what is considered revenue (it’s not always cut and dry), but if you’re paying software developers more than the project is bringing in, someone should begin asking questions. Startups might be considered exempt but they shouldn’t be – at every iteration, this has to be looked at and with startups even more so than mature projects. Why? A misstep could be the end of it all.
  • Underlying Technologies Are No Longer Competitive/Supported: If you’re required to run a project under DOS or CPM, it may be time to pull the plug. If there’s a niche market, that’s nice. Just make sure that the niche market is paying your overhead and profit. Another example might be a lot of code that is not compliant with the latest and greatest strides in the language. I’ve seen PHP 4 code stuck on LAMP servers that belong in museums – running live on the Internet, where script kiddies are more than happy to show the willing that it’s time to move on with their probing.
  • The User Demographic Says So: Users are a peculiar group of people who don’t necessarily write long and detailed emails about what you’re doing wrong for them – in a world full of software options, it’s hubris to think that your company is so special that your users should invest themselves in your product. Social media makes getting feedback easier but tweets like, “your product sucks” just don’t give the granularity necessary to steer the project.

There are no silver bullets in here. Everything has to be considered within the context of the business and the key problem is that there’s a level of introspection required that wouldn’t have allowed the software project to get where it is now. It can be an uphill battle with those who make decisions since they may have seen how much they invested in the technology in the past as some form of wedding ring.

Image at top courtesy Louise Docker, who made the image available under this Creative Commons License.

Economy and Collaboration (2015)

Bee and Flower macros

Colin Shaw’s post on LinkedIn, “Collaboration Is Dead: Long Live Symbiosis“, indirectly addresses one of the key problems with understanding Open Source and Free Software, not to mention Open Content.

Sure, with Free Software/Open Source and Open Content there is collaboration – but if you look at the most successful projects, you’ll find one major thing: An economy surrounding it. Linux grew its economy by decreasing the cost of servers and other hardware by ‘removing’ the cost of software licensing. The software is still paid for but it costs the end user less. WordPress has an economy around it, as does Drupal – though the economies are quite different between the two. The point is that all of these well known open source projects have an economy that reinvests in the projects. Sure, we can call it collaboration and do a happy dance – that has been done for at least 10 odd years (in both senses of the word), but the reality transcends collaboration and is more accurately called symbiosis. It’s something that has bothered myself and some other people for some time but… for some reason I never jumped at ‘symbiosis’. Shame on me.

Symbiosis is truly key in any business sense and far too often open source, Free Software and Open Content advocates do not acknowledge that. ‘Free as in Freedom‘ has to take into account TANSTAAFL – where the Free Lunch was never about the freedom to eat lunch. You can only write so much free software/open source before the bill collectors say, “Hey man. Love your code. Pay me.” The same applies to open content.

The same applies to Social Media – or just about anything except, hopefully, childhoods. In the context of social media, it’s about getting at least as much as you give to your network.

Symbiotic relationships where the profit is mutually exclusive are seen throughout nature, much like the bee in the photograph. The bee gets something. The flowering plant gets something. Everyone’s happy.

I think it’s time to put collaboration in the rightful place – decremented – while symbiosis is really the goal.

The sound of one hand clapping is a very lonely sound.

Image at top left is my own; you can view more of my pictures either through my Flickr photostream or in my Photography Showcase.

 

Enhanced by Zemanta

Technology And Arts

Sisyphean TechnologyPeople in technology of my era and later are strange creatures that delve into the depths of understanding the cold and relentless logic of systems that they create and maintain. We see the same in other fields, in Law, in Medicine, Accounting and so many others.

Today, as Lessig wrote, ‘Code is Law‘, and Law wrestles with technology even as technology works to circumvent existing Law. Law, as a freshman student will tell you, is not Ethics – it is an attempt at the codification of Ethics in a society. That distinction is important yet routinely forgotten by many – and that’s where some empowered by technology have an ax to grind. Others are just in it for the money, or for some political agenda.

One of the problems we face, as a global society of screen-watchers, is that we have separate silos of technology and arts – where technology is often used as a platform for the liberal arts.