Done.

cea_buddha
Image used with permission of photographer, Flickr user cea. Click for original.

I don’t miss it.

There was a time that it didn’t seem like I ever could. It was all I did. Coding, designing, architecting, playing with new languages and frameworks – it was great. I spent hours upon hours getting good at things that were, in the end, just passing fads.

Passing fads with ‘benefits’, really. The ‘benefit’ being the ability to find work maintaining someone else’s crappy code. Maintenance.

No one looks forward to a career in software engineering maintenance.

But that’s the majority of the industry, and if you’re good at maintenance, they’ll pick someone else to do the new development no matter your experience level. They need you there with your finger in the dyke as you watch them do it all over again – making similar mistakes.

No, I don’t miss it.

CubicleLife

I don’t miss sitting in meetings to watch other people beat their chests and claim credit for things that they didn’t do as political necessity. I don’t miss reading emails written by people more interested in trying to impress each other rather than actually communicate what they need to.

I don’t miss being told I should be at my desk more often when I was one of the few people meeting deadlines, milestones, yardsticks and tombstones. I don’t miss the tiresome code-jockeys who don’t know a thing about process and were graced with writing them. I don’t miss going through undocumented code and figuring things out to rewrite a new iteration that will never be used. Oh, and if you were ever on call…

There’s really a lot not to miss.

And as software engineering goes, that’s pretty much the way it is. That’s a pretty average career, since most work in software engineering is maintenance – and maintenance, after a certain period, shows you everything that was done wrong. But since you’re doing maintenance, you don’t ever get to use it at work. Maybe you do it at home, but honestly, after a few decades you may not want to stare at a computer when you get home.

No, I’m playing these days. I finally got back to why I started it all in the first place.

Except I have a lot more experience. And I can walk away from my desk, I can eat what I want when I want, I can wear what I want…

Cubicles? Offices? That’s for managers.

The Best Programming Language To Know – Ever.

Nobody understands me!Amongst geeks, invariably, the topic comes up eventually – it’s sort of like mentioning Hitler on the Internet. The best programming language. The best framework.

The best… whatever.

I even caught myself getting into a similar discussion recently about the best programming language to learn with, and being drawn into discussion. It shouldn’t even be a topic. It’s downright silly. The best programming language to start with is your native language – in my case, that’s English, in your case it’s likely English too – after all, this post is written in English.

One of the first things I wrote professionally was about how to start learning to program. It netted me $300 U.S. from CramSession.com, now beyond the most extreme measures of resuscitation. 17 years later, I can lay it out in a paragraph. Fortunately, Cramsession.com can’t ask for their money back.

Everyone that can write and execute a shopping list can program. You know what you need from the store, so you write the list – so the first pass is the list. The second pass would require a mental layout of the store for the most efficient path to walk through and get what you need – so you then prioritize the list based on aisles. Then you can get more finely tuned based on which side of aisle things are. You’re a programmer now. Show us your grocery receipt. Frame it. It’s your certificate.

Of course, over time you learn that the store moves things around, so you now have to maintain whatever you wrote by adapting it to changing circumstances. Welcome to maintenance, the most numerous jobs in software development. 

The best solution I ever saw to the Fizzbuzz problem was submitted by a non-programmer who simply drew a flowchart. It demonstrated to me that she – it was a she – understood the underlying concepts and could implement them in any language since she understood the underlying algorithm. Sure, there are a lot of solutions to the Fizzbuzz problem (what a horrible way to measure whether someone can program!) in various languages – from elegant to obfuscated – but programming languages are not the most important tool for tackling a problem. The most important tool is the language the problem comes in. A half-decent programmer, given some time to get their feet under them with a programming language’s syntax, can write a solution in any language.

Therefore, the most important language in programming is your native tongue. Some will argue that it’s English based on demographics, but those demographics have been skewed by economic development and market sizes. If you can’t think clearly, you can’t write clearly – as a programmer, or as a writer. Period.

Now somewhere there’s a geek that is stridently making a case against what I have written, but the beauty of it is that the case they are making is probably in English – the language this is written in. Right now, they are making my point for me.

As AI becomes more relevant, natural language programming will go from a way to create systems that understand natural language to actually programming those systems in your native language. The language of the market dictates.

Suddenly, that Oxford comma may be more important to you than you think.

If you don’t know what an Oxford comma is, now is a great time to use Google to begin your research.

Technology vs. Bureaucracy: a T&TEC Connection

ElectricityOne of the less fun things I get to do in dealing with land ownership is assisting people in getting electrical connections from the Trinidad and Tobago Electricity Commission (T&TEC).  The legitimate way of doing this is the land owner giving permission for the connection to the person getting the connection.

The why of people getting connections on land they do not (yet) own is fodder for another post on Land Laws in Trinidad and Tobago – but take it on faith that it’s done.

In 2008 I did this for someone. 9 years later, I’m doing it for someone else.

First, I’ll tell you how it happens. Then I’ll tell you everything that is wrong with it.

How it ‘Works’

The person getting the connection has to present evidence of land ownership or permission from the land owner. To do this, T&TEC wants to see a deed, and they want a letter from the landowner if the person does not own the land – as well as identification, which they diligently photocopy and probably place in a file somewhere marked, “Kill Trees”. Simple enough, you might think.

To make things easier, a landowner can send a photocopy of their ID and deed along with the person getting the connection.

That gets them ready to get an inspection done. The actual connection requires… all of the above again.

Since I’m not one to send someone running around with photocopies of my ID and deed, all of this means I get the joy of going to T&TEC in San Fernando, where they refer you to an orange desk which is now closer to a pink salmon (I asked a woman with matching nail polish what color her nails were). We sat there for an hour or so, watching frustrated T&TEC employees chained to keyboards of a system that was ‘giving trouble’, got to the desk and – fortunately – I had prepared everything for them so that in 15 minutes of photocopying and signatures, I could move on with my life. I don’t know how long the person getting connected stayed after.

How it Should Work.

A lot of people don’t know that T&TEC, circa 2010, mapped T&TEC poles all over Trinidad and Tobago and has them on a map. They can, with accuracy, tell you where they have their poles. And these are on a map of Trinidad and Tobago that had, or should still have, an up to date list of all the surveys registered in Trinidad and Tobago.

I say this because anyone with a deed can walk in and get someone else connected on someone else’s land. That’s clearly fraud, but it can happen by mistake when a land owner doesn’t know where their boundaries are. Therefore, the requirement of the deed is actually worthless without a survey that shows where the connection will be.

As I recall from years ago, I had to do this for a Water and Sewage Authority (WASA) connection around 2010. In my opinion, this is more in line with Land Law in Trinidad and Tobago, but I am no attorney and do not play one on the Internet.

The registered survey than be searched for if it were linked with the Ministry of Planning And Development, Town and Country Division systems. Then that would, if connected, be able to search the registry of Deeds at the Red House (which does not yet seem computerized).

If this were done, it would be apparent who legally owns the land, whose permission would be needed, etc. It would, of course, require the various databases to be kept up to date and interconnected.

And identification? Does no one see a flaw in accepting photocopies of identification not done on site? I could easily scan something in and alter it, printing it out. No, instead why not just have the T&TEC employee verify the identification is legitimate and enter the relevant information? Why are we killing trees in 2017 over this nonsense?

So, why hasn’t all of this been done? Why should this be hard to do? Why not remove the potential for error and corruption by appropriate use of technology?

There’s a question that should haunt every government administration since Independence. It’s a symptom of the larger problems, the elephants in the room that have ground the fine china into powder. Ministries not working together, a lack of a holistic vision, and a flood of ‘we like it so’.

I now return you to your regularly programmed bureaucracy.

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.