Using What You Have

Up Above It...At the beach this morning, there was a grey haired, bearded man of advanced years taking pictures of the sunrise. He was contrasted with the twenty-something young woman doing the same.

She had a full on setup - a good tripod (not the cheap ones you get that aren't that stable) with what looked to be a Nikon DSLR. She was over there fiddling with her equipment, getting things just right before she took her shots.

The older man was using the hand railing for stability and taking shots with a point and shoot.

They were probably achieving similar results.

The younger had the latest tools, the best her money could buy and was finagling herself to better pictures with considerably more effort than the older. The older was using what was around him to his advantage, using it to achieve a similar effect with significantly less error.

It's a great thing to consider in the world of technology, particularly in software engineering. The selling point of technology is that it's supposed to make life easier, and software engineering products are supposed to inherit from that. It's supposed to be easy to use, and in the grand scheme of things, people want it to be inexpensive (though they will pay for what they want, which explains Apple products - for better and worse).

Using what is available to achieve the same result seems ideal in most software engineering scenarios - thus, object oriented programming has lasted so long. Throwing more money at things can simply make things more expensive and time consuming to maintain. It does seem to take experience to know the difference.

Killing the Yoda

Yoda vs. Hulk (164/365)In technology, there are neverending aspirations to be better - and one thing in common with technology is Yoda. Well known he is to the technology community.

There's a Buddhist koan that I've derived from for this post. It states that if you find the Buddha, you should kill him (Linji). It's not a literal saying, it's about people being on their own path and aspiring to be more.

It's a good thought. You can read more about killing the Buddha here. The same thought adapted is to kill the Yoda.

The idea here is that any predominant technology, best practice, software architecture, software process... even education related to any of that (or anything else) is a stepping stone.

How does this apply to software? Let's say that you write the best possible application for real time widget updates. It's your Yoda. Someone else with either a lot of time or a lot of money is going to kill that Yoda unless you kill it yourself and replace it with another Yoda. In fact, that's what Software Development Plans are partially for- defining the End of Life for a project, and every project should have one. Otherwise, Yoda++ will take your Yoda down.

That process you think is perfect? It won't always be.

That architecture you think is perfect?

Those 'best practices'?

Yoda's your pal now. Be ready to take him out.

(Throw Jar Jar Binx under the bus while you're at it).

Best Practices, Software Process and Architecture: Stuck on the Tracks

Man fixing railroad tracksOnce upon a time, I was a member of the Software Engineering Process Group at Honeywell. I'd already had access to what was done so far for our division, so I got a copy of The Capability Maturity Model: Guidelines for Improving the Software Process (almost completely outdated by the new CMMI). I got sent off to class and learned more than I expected.

In fact, one of the key things that always got pressed home was that the CMM was a guideline, and that many companies were using the book as The Law. It was never intended to be. It was intended to be adapted, to fit the business need, and to add value.

Therein lies the rub. Fairly frequently in the software development and engineering circles, some new 'best practice' pops up, some new way of looking at software processes, or some new software architecture gets evangelized. Generally, it's expected that whatever is newer is better. It's expected that software teams - of whatever structure - should be getting better. Sometimes it does, sometimes it does not. Petronius is often cited for this particular quote (I attribute it properly):

We trained hard ... but it seemed that every time we were beginning to form up into teams we would be reorganized. I was to learn later in life that we tend to meet any new situation by reorganizing; and a wonderful method it can be for creating the illusion of progress while producing confusion, inefficiency, and demoralization.

- Charlton Ogburn (1957)

Technology is rife with this. End users line up for it, software developers and engineers are swayed by new ways of looking at old things, as is management. Things done right for years can be turned on their head because of something 'newer' and allegedly 'better'. Entire programming languages and operating systems have risen and fell.

Sometimes some good comes of it, such as measuring the productivity of a programmer by Source Lines of Code - though these days it does seem to be commonly measured by how much they sit in a chair or how many hours they put in staring at a monitor (we'll fix that eventually).

Can you fully test that legacy application, or do you need to grandfather it in and only test modifications (in the hope that undocumented features aren't broken)? Do you patch your software with human process or do you patch your software? Do you stick with a n-tier architecture or do you adapt on it so that your business needs are better met? Do you code review every change, or do you only code review release versions to assure synergy doesn't create new issues? Do you abandon a code base because it won't work with Windows 10, or do you support it as little as possible until it is not relevant?

Everything, from architecture to software process to best practices needs to be adapted to the business need. Why? Because without the business need, no one gets paid.

Sometimes you need to jump the tracks. Or adjust them. And if you're spending more time adjusting them than getting things done, you have a big problem.