Month: April 2016

Trains, Talent and Tech

~ Taran ~ Leave a comment

Wherever you are, what is happening with the infrastructure is always important for personal reasons – and also for professional reasons. For me right now, that means New Smyrna Beach here in Florida and, therefore, Volusia County.

In this case, I was having a conversation on Tom Laputka’s post about SunRail getting to Deland.  Tom’s running for County Chair here in Volusia County this year – we met through one of the Veteran get-togethers; his son is a veteran.

What does this have to do with Technology?

Everything.

Recent professional experience demonstrated the issue with getting talent in the Volusia County area for technology companies is a problem, even more so as you get to the beach. You’d think getting the folks out of Orlando to the beach areas would be easier, but it’s a leap of faith on an individual level. There just aren’t that many technology related jobs near the beaches, and I could speculate about why that is with a fair amount of certainty, but not here.

As Steve Traugott mentioned in the FLOS Caribbean conference in Trinidad and Tobago, back in 2003, the true power of Silicon Valley isn’t the venture capital – and it most certainly doesn’t have a monopoly on coming up with good ideas (though Silicon Valley marketing might have you thinking otherwise). It’s that they have intellectual capital in the way of people that cycle from company to company, building themselves as individuals and thus building the technology base.

As Jeff deGraff, Professor of Management Education at the University of Michigan, recently wrote:  It’s the Talent, Stupid.

Individuals moving takes risk, and Florida, which certainly doesn’t lead anything when it comes to public transportation, is derailed in this regard because commutes are annoying. Since I was stationed in the old Navy base in Orlando, I4 has constantly been a state of being fixed and all that has effectively been done is the moving of potholes. The traffic is miserable, particularly in tourist periods.
So Sun Rail getting as far East as Deland offers the opportunity not just for people to get to the beach from Orlando – it opens the area to more technology growth through talent growth. Orlando can beef up it’s technology base without causing even more wear and tear on it’s already beaten and congested path. If you’re interested in the environment, it offers more clean transportation and the ability to live outside of the bounds of Orlando.

Why this even required support letters boggles the mind. It’s win, win, win. Were enough sent in?

We’ll find out. Last year, sadly, it failed.

 

 

The Reason Why Your Tech Employees Are Leaving

~ Taran ~ Leave a comment

SH-dinky-I-quitThere’s a bazillion articles out there on employee retention the last time I stopped counting. Tech employees are slightly different. Without further ado:

1: They’re Unhappy.

Tada. This is why people leave.

Tech folk are a bit like cats, and herding cats is not an easy task. People want different things. If you don’t know what the individuals want, you’ve already identified your first problem.

You can’t and should not please everyone.

You might be amazed at how easy it is to retain employees if you simply listen and react appropriately – and bear in mind that the rest of the team is paying attention and taking note.

1a: Hot And Cold

If there is no respite, if it’s a matter of going from one thing to another, running hot on projects behind schedules and cold on new things, you’re encountering basic physics. Constant expansion and contraction is not good for anything, particularly people. The larger the gradient between hot and cold, the more likely you’re going to lose people. This is part and parcel of a Culture of Fear.

1b: Unfair Treatment

You might like to think that you’re treating everyone equally, but your team might see it otherwise. If one person throws a tantrum and gets what they want – be it a supply of Coke products or an office – expect the rest of the team to either learn the lesson or begin disapproving of management (if they haven’t already).

Further, if you ride one person hard but let another get away with murder, you’re asking for it. While you may have higher expectations of one or the other, inconsistency in how the team is treated fractures the team.

1c: Rewarding Jerks

When you reward someone who is not a team player and is constantly creating friction, and when they get away with just about anything, it’s a matter of time before either (a)people start acting like jerks or (b) they pack up their toys and go home.

If you find yourself in a position where you have to pick between two employees, it’s already too late and you should be wondering how that happened in the first place.

Bear in mind, treating a jerk and someone who is not a jerk the same when dealing with an altercation gives the jerk the high ground. Do that consistently, expect the non-jerk to walk. Maybe just spontaneously one day.

If you can’t identify a jerk, you have much larger problems. If you like the jerk, you’re a jerk – and if you don’t like the jerk and keep the jerk, you’re a jerk. Embrace it and stop reading here.

1d: Bad Priorities

You (hopefully) hired smart people, and while you may not show your cards, people can discern bad priorities when they see them – or worse, they can believe that it is a bad priority because your organization lacks the transparency for them to see it as good.

Tech folks generally like to feel like they are doing something of worth.

1e: Not Involving the Team in Big Decisions

This doesn’t mean that the team has to agree on everything, but if it’s a decision on how something will be done across the team, get input from the team as a whole. And if you have people who steal oxygen from meetings, make sure they don’t monopolize the time or frame things such that it’s their way or not.

1f: Lack of Growth

If you’ve hired people who don’t want to grow or help the team in greater ways, you hired wrong and you have larger problems. This is not to be confused with the Empire Builders – those that harden their position and are constantly finding ways to make themselves relevant in places where other team members might be greater assets.

1g: Influence Issues

Someone who has developed influence in your organization by hard work and perseverance is an asset, and while they will likely be resistant to changes you want to implement, if you leave them out of Big Decisions (see 1e) you may well be shooting yourself in the foot. If they don’t get upset, or suddenly stop becoming upset, they’re on their way out – which may or may not be good.

If you have someone who has accepted increasing responsibility, knows how things work that you don’t understand and has gotten in front of problems… you may not appreciate them because they’ve kept the flames from creating the tell-tale smoke signals. Unfortunately, when you smell smoke after they leave or just before they leave, it’s too late – so pay attention to how people get in front of problems.

1h: Money

Yeah, money had to make it in here somewhere but I purposefully left it down here as the last one. Why? Because if people are having trouble making ends meet they WILL look. If your tech people are having that problem, that’s a big glaring issue you will pay for if you don’t pay for.

Money isn’t as much of an issue as people make it out to be – the people who just want more money will likely leave anyway when they get a better offer, and you might be better off without them.

By the time someone starts comparing salaries, they’ve already decided to start looking. Even if you pay them more, they’re likely to leave anyway – except the unicorns. They do exist and typically negotiate more than money.

This post also made available on LinkedIn.

Evolution: Process Trumps All

~ Taran ~ Leave a comment

3D view of Mar03wjc1bOnce upon a time, software was sold on disks that were actually floppy. They were encased in boxes, with user manuals.

Then the disks were no longer floppy, but they were called floppy as a sacrifice to the Gods of Inaccuracy.

Then the Internet came along, and you could buy the boxes over the Internet.

Then you could download the applications over the internet when you purchased them.

And finally, Software as a Service (SaaS) came into being, and all was basically the same only faster (and with significantly worse documentation).
And the people were generally as miserable as they were, and could be disappointed at a faster rate when they found bugs, or when systems went down, or when their internet access was sloppy.

The real difference between competing companies now is how they produce and maintain the software. That’s the process.

Bugs happen. How fast can the bug be fixed, without introducing new ones? That’s the competition. That’s where competing companies actually should be competing, because the faster a company can fix bugs, the faster it can implement things as well.

That boils down to Software Process. And that’s why Agile, Lean, DevOps and so on are so important.

Because nobody is ordering boxes from the back of magazines anymore and getting it in the mail a few weeks later. They want it now.

If you don’t even have a software development plan (SDP) for a project, you’re already behind.

 

 

 

The Long, Dark Tea Time Of The Career

~ Taran ~ 1 Comment

NSB SunrisePeople don’t write about this stuff. I decided I will.

Without going into the details, I left the last job after a resignation, taking it back, and after realizing it was the same thing, resigning more efficiently. It’s not a bad company. It wasn’t good for me.

Let’s leave that where it is.

I had irons in the fire, of course. In a lot of ways I still do. I already had bad headhunters annoying the hell out of me, and some good headhunters with some interesting positions. I was courted by some CEOs and CTOs through LinkedIn.

That was a mistake. There are jobs, and there are careers.

Some things came into play and suddenly I had more breathing space to think about it – freed from the tyranny of income for a period, I could stop. Reflect. Think. Feel. Assess myself, inventory myself, decide what comes next. It’s a luxury in this day and age where salaries don’t allow for the mobility that they once did (and, kids, they did). If you have the luxury, though, you should take it. Taking it I am.

It took me about 3 weeks to forget about the last place I worked – not completely, mind you, but in some ways a job is like a shell – it provides safety once you conform to the inside of it. As I told my last boss at the beginning of 2016, “ultimately the only thing an employee can control is whether or not he or she works at a company.”

After the 3 weeks had passed, I found that I had been doing more creative writing again. I had dusted off my camera and started shooting again. I started reconnecting with people who I  had lost touch with, as one does when one gets into the intellectual toil of more work than play. I recognized myself a bit more every day, like a stranger becoming acquainted with a reflection in the mirror.

A friend at a coffee shop asked, “Why don’t you talk down to people like other software developers do?” I paused. I thought.

“I guess I outgrew that at some point.”

I have. I’ve outgrown a lot of the bad things and have evolved beyond being a Software Engineer, or a Writer, or a Technical Writer, or a Consultant. I transcended technologies some time ago, becoming agnostic after having spent time in the Microsoft corporate code caves and the Open Source code caves. The leadership qualities became more pronounced, my patience for the mistakes of others had grown and the lack of patience for mistakes of others had also grown. I’ve been published, suffered the editing of others and rejoiced at how they helped me grow.

I watched all manner of software process succeed and fail, and understood why. I pick up technologies like some pick up novels but I have become a picky reader. After seeing languages, technologies and architectures wax and wane, you become picky. That cool new technology doesn’t impress me if it does nothing new, and just because you can develop faster in it doesn’t mean that the end product is better. Typically, the faster you can develop in something, the more dependent you are on third parties that don’t care about your project.

I clean up ok.This guy is pretty different than the kid who started off in the late 1980s with the only real aspirations of getting out of a miserable household and being a professional computer programmer. Right now, that guy on the left doesn’t exist. His hair is unkempt, a full scruffy beard across his face, his focus inward. The man who would normally go out of his way to help his friends is suspended in carbonite, a caricature of a guy who shot first. It’s not selfish, it’s self-preservation. It’s coming to grips with what comes next, figuring out what that guy needs, what that guy wants – who that guy is. The kids aren’t going to understand this, and I imagine people with families at my age are too busy to dedicate some time to thinking about it until their children have not only left the nest but have stopped calling for money.

You see, you’re not supposed to write about all of this. In society, it’s taboo to write about this sort of thing publicly until well after the fact. To do that, you’re supposed to have that success that comes from a magical period like this – but that’s uncertain, fickle and cliche. It lacks originality, though originality is not something that is admired as much as people would want to think in this world – take a read of “Originals: How Non-Conformists Move The World“. It’s harder to live than to read about, like most things.

I have a deadline. The second week of May, 2016, for no good reason other than Cinco de Maya with Tequila seems like a bad time to make life decisions.

HowTo: Twitter Header Size 2016

~ Taran ~ Leave a comment

Storm

In the past, for Twitter, I just tossed one of my many beach sunrise photos at it and let it do it’s thing. This time, I didn’t.

Yesterday I made the image on the right. There was a meme going around, and I had this picture of a North American Osprey in the forefront of a storm, and I thought – why not.

Then I was looking at my Twitter page and thought, “That might be a good header”. So I tried changing it and, lo, it was too big and didn’t resize right. So – I had the wrong dimensions, and through a search I found out that the Twitter header size is supposed to be 1500 x 500 pixels. I resized the image accordingly.

Same problem.

I tried Chrome and Firefox (I typically use Seamonkey). Same problem.

I did some more digging, tried a few different sizes. Still, no. Same problem. I tried for searching for things like, “Twitter header too big” and came up with the same awful pages that hadn’t helped me in the first place. Some offered to resize it for me, but tada – same problem.

I went from searching for the right answer to hacking my own.

It took me about 15 minutes (as long as it took to write this) to come up with the solution.

If you’re having a similar problem, try changing the canvas size such that you have 100 pixels above and below (add 200 pixels or so to the canvas size, centered, and there you go). Fill it with a similar color just in case.

Try it out. Tweak it if necessary. You’re done.

And a sidenote to Twitter – did you actually think about how screwy this is?

6 Things To Answer Before Posting You Need A Website

~ Taran ~ Leave a comment

Avdanced Web Design I don’t want to do your website. I’m posting this because it bugs me.

I’m going to tell you what so many people are doing wrong on websites like Upwork, Thumbtack and others when it comes to, “I need a website done” postings.

These are good sites, and if you need something done, they’re pretty awesome. Need a room painted? Need something fixed? Get a bid. Move right along.

When it comes to websites – and I’ve been watching a few of the postings on sites like this – the postings tend to be horrible. Here’s what you need to have if you’re going to post that you need a website.

1. What Does Your Business Do?

This could be a personal site, but let’s approach it like a business.

What do you expect of this site? What sort of expectations you have are very important to get a real quotation.

For example, if you just want a placeholder site – with your contact information, maybe a copy of your resume and/or portfolio – say that.

If you want to be able to process credit card transactions for selling those magically painted seashells, say that – and if you plan to do it not now but in the future, say that as well.

2. Do You Expect To Need Maintenance?

This is almost always a ‘yes’, though most people don’t seem to understand it. The internet is constantly evolving and your site will have to as well. You’re looking at a recurring cost. What will that be?

3. Do You Have Content, including Logos?

If you’re asking someone to generate content for you as well as do the website, know that these are separate tasks. Sure, there are people out there that claim to both – but their catch-phrase may be, “All Your Site Are Belong To Us”.

Search Engine Optimization (SEO) is almost always an issue here unless you want no one to find your website. What do you want to be found for when people search?

Further, if you are doing a website and don’t have a logo, you shouldn’t really expect a web designer to do it. Logos should be done by graphic artists, and a lot of thought has to go into them. Are they going to be on stationary? Are they going to be registered trademarks?

Do you have your own photographs?

4. Do You Want To Post Your Own Updates?

This is a magical question. If you do, and you are willing to invest a little time to learn, WordPress.com presently takes $99 of your money and register your domain name (MyAwesomeBiz.com might be taken) – and has a pretty easy to learn interface… which you may have to learn anyway after you find out that when you thought you needed maintenance and so on, you do. (See #2).

5. Social Media?

How are you planning to use your site with Social Media?

6. Are You As Certain As You Were When You Started?

These questions – real questions related to a real web presence – may have you going back and revisiting your website. And if they do, you should:

“There is nothing quite so useless as doing with great efficiency something that should not be done at all.” – Peter Drucker

 Don’t waste your money going off half-cocked. If you do, you’ll end up spending more and getting less.
If you really need help defining what you want, drop me an email. If I have the time and you are willing to pay a fee for my time, I’ll give you worthwhile advice. If you’re in the Daytona Beach/New Smyrna Beach area and catch me at a local coffee shop, I might even do it for free.

Getting Past the Mystery of MVC

~ Taran ~ Leave a comment

One way for Software Engineers/Developers/Programmers to impress the hell out of Managers, Directors and Executives is to confidently shoot acronyms at them in rapid fire. Dilbert is rich with this; since the late 90s I’ve sometimes tossed ‘EIEIO’ into the mix when I heard it being abused.

MVCOne of these acronyms is MVC. It’s really simple. See the image on the left? It’s that simple. And it’s not new by any stretch. It’s great for architecture of small systems, and done properly can do well for much larger systems – if you understand how to define the Model, the View and the Controller.

I say it’s not new. In fact, it was introduced in 1978-1979 by Trygve Reenskaug and others for the Smalltalk-76 programming language at the Xerox Palo Alto Research Center (Xerox PARC). You can figure that it has been around almost 40 years, and that it’s from the same era as the mouse and the graphic user interface (GUI).

As a concept, it’s fairly solid – and used properly, it can be powerful. But it doesn’t mean that every system should be MVC – in fact, with application development the way it is these days, a lot of systems probably shouldn’t. Why? If you’ve got multiple application programming interfaces (APIs), you may be going down the rabbit hole into complexity and making software entropy that much more accelerated within your Software Development Life Cycle (SDLC). This article makes that point quite well and offers alternatives, though it stops before getting to some of the conclusions I draw.

So let’s get to the crux of MVC. It’s one of many architecture patterns out there, and the main thing that really needs to be talked about in the context of MVC it’s about implementation – languages and technologies that allow for proper use for MVC. Some don’t give as much flexibility as others.

And MVC isn’t always the answer – more often than not, in the last 2 decades, I’ve seen it used as the straws a drowning application clings to. It’s not bad – it’s not good. It depends on how it’s implemented, and proper implementation in a complex and open system – which describes most – can be outright scary.

A good Software Architect knows these things. A good software architect puts the complete system requirements ahead of the architectural skeleton that is to be and decides on the architecture – while planning for future growth.

Is MVC right for you? I’d say mostly yes. But don’t think it’s new. It’s the architecture that has lasted 40 years and has brought us the applications we have today. Is it the right architecture for the future of your systems? That is a question that should be posed to architects to challenge them.

Your mileage should vary if you’re doing it right.

 

The Confusion On DevOps

~ Taran ~ Leave a comment

devops in a boxI was in an interview with a candidate for a Software Engineer some time ago. We had the usual suspects at the table and me, the unusual one at the interview.

I’d read the guy’s resume. He claimed some game programming, and he also claimed to have experience with the full SDLC with both the Waterfall and DevOps methodologies. One of our people, notorious for academic questions, was pulling some of his punches related to .Net. He trotted out his usual questions on design patterns (he sure did love his MVC – let’s call him Mr. MVC), and he continued with his notorious monopolization of the interview. When it finally got to my turn, I asked a XOR question – the candidate had never used it.

So then I asked him about the strengths and weaknesses of Waterfall – and on DevOps. Mr. MVC quipped that he didn’t think we were hiring for the DevOps department, and I ignored him since I did not want to straighten out his ignorance in front of a candidate (though he had no problem being a jerk when he was wrong). The candidate answered the questions well enough, and I let it be.

But looking back, I couldn’t help but think that Mr. MVC was confused by DevOps because:

(1) We had a department by that name.

(2) He didn’t actually know about what DevOps was,

(3) He hadn’t read the resume and noted ‘using Waterfall and DevOps methodologies’.

It surprised me that Mr. MVC didn’t know about it, and it surprised me more that he’s now basically in charge of the Agile process at that company but wasn’t familiar with DevOps itself – particularly when the end goal is continuous integration. That’s sort of what DevOps is:

…Agile software development paved the way, steering away from the waterfall method of software development toward a continuous development cycle. But it didn’t include the operations side so while development could be continuous, deployment was still waterfall-oriented.

In a DevOps environment, cross functionality, shared responsibilities and trust are promoted. DevOps essentially extends the continuous development goals of the Agile movement to continuous integration and release. In order to accommodate continuous releases, DevOps encourages automation of the change, configuration and release processes…

So, by having DevOps on his resume, the candidate had opened himself up to all manner of questions on Agile, as well as continuous integration – things which, months later, would be brought up by the CTO.

And no one – not one soul – called it DevOps. Why? Likely because they got rid of the department that they used to call DevOps. This was largely because they sabotaged it by not giving it the appropriate tools for continuous integration, and the fact that the lack of documentation made the relatively fresh department more likely to fail with manual deployments.

I write all of this because I encountered it at one of my own interviews with a company. We were talking about continuous integration and the mismatch between Agile and Continuous Integration when it comes to involving Operations – they are typically not involved with Scrums and are therefore less likely to be prepared. That’s where DevOps comes in.

DevOps has been around a while. Waterfall went to V-model that went to Agile – and now DevOps is king. Or should be.

But it’s surprising how many people don’t know about it.

Suggested Reading:

Avoiding Complexity In The Software Process

~ Taran ~ Leave a comment

ComplexityOne of the greatest enemies of software is complexity, since it invariably leads to Software Entropy. It increases the cost of producing software. The good news is that we’ve gotten better over the decades at assuring best practices steer away from complexity – but sometimes people who implement the software processes themselves do not understand the why of things and create complexity in the software process itself – and even create new and interesting problems.

A simple thing like code reviews can be made complicated by different disciplines sharing the same space. Let’s say that you have code that uses stored procedures. Clearly, you’ll want a DBA doing the review of the stored procedure(s) and table changes – you might not want to call it a code review, but it is a review of a sort. Would you create a new column on your Agile board to track DBA reviews? I would hope not, if you’re using a decent tracking system. You can expect a DBA to make loud noises about them being so different, but if you take a step back… it’s just another type of review that can stay on the board without adding complexity to the board.

Further, differentiating that from the other reviews almost always assures that the code review and the review of the SQL related code is done separately – and since they will go into Production together, it would make sense that the reviews be synergistic. The Software Engineer and the DBA should review together, not separately, so that there are no assumptions made. The short term ‘gain’ of doing them separately results in a potential loss of quality.

How could it be done? Sure, the DBA needs to know to do the review, but that can be done by assigning two people to the review (a DBA and an Engineer) or creating two linked tickets for the same issue and making sure that the review is done at the same time. Simplify, simplify, simplify.

Simplify. It will take a little more time, but it will avoid quality issues – and keep your Agile process more simple.