Tuesday, December 08, 2015

Open Source Trumps the BSA

The BSA has apparently started another campaign. I use the word "campaign" in the same sense that it would be used to describe Viking raids. Here's what's circulating Facebook:


The BSA has no interest whatsoever in stopping piracy. What they do want to do is collect money for unlicensed software. That's not a subtle difference.

It hurts YOU to destroy your employer. The awards from a court settlement can bankrupt a small business. You'd be awarded a cash amount that can equal one or two regular paychecks, and you're pounding pavement, competing in interviews with your former co-workers.

Here's a better idea... Show them the BSA's ad and suggest a move to Open Source software to remove the liability of unlicensed software. LibreOffice can fully replace Microsoft Office. Lose Outlook and replace it with Thunderbird. Ubuntu Server can eliminate Exchange. Alfresco replaces Sharepoint. GnuCash does accounting. Gimp is free... Photoshop isn't. You don't even need to license Windows when Linux is in the house.

And libre software plays well with licensed software. By switching to Open Source where you can, you free up funds to license software you NEED to license, and that gives you a leaner, better, more profitable business. That's a lot better than wasting money on commodity software like word processors.

Tell your boss.


Tuesday, October 27, 2015

KillChrome.bash

It's been a while since I've posted here, but I've got a little trick for the Linux users today.

If you're using Chrome on Linux you may have noticed situations where Chrome doesn't open properly. It reports  "Your profile could not be opened correctly".

Some resources on the web tell you that your profile is corrupt, but that's actually the least likely reason. More likely, you've got abandoned processes that have possession of the file. All you have to do is terminate the processes. The bad news is, there are often a lot of them, so it's tedious to do manually without logging out of the user account. The good news is that it's simple from the command line, and therefore simple to script.

Make a text file (mine's called killchrome.bash), paste this into it, then save:
#!/bin/bash
pkill -9 chrome
google-chrome
Modify the file properties to be executable. You can do this in GNOME by right-clicking the file and editing properties, or you can do it oat the command line like this:
chmod +x killchrome.bash
If you like, you can assign it an icon. The image here is the one I use.

That's it. The next time Google hangs on startup, you don't even have to exit the program. Just click killchrome. It will clear out all the zombies and re-start the program.



Saturday, June 13, 2015

About Planning

Here's a little something that I was reminded of recently. (Not that everything in this post occurred recently, but I was reminded of it).

I wear a lot of hats. Sometimes I'm a project manager (PM), sometimes a functional analyst (FA), sometimes a technical analyst (TA), sometimes a programmer/analyst (PA). Occasionally I'm acting in the role of quality assurance (QA) tester, or even in a purely consulting role. Sometimes its several of these, and sometimes it's all of the above.

I'm often asked to estimate project work. This puts me in an analyst role on behalf of the programmers. Now, estimation is often described as a "black art", but there are a few things that project managers should always remember. These are not exhaustive, and are not in any particular order. And I'm not going to talk in terms of some particular methodology. This is simply some common-sense advice that you can apply anywhere.
  1. An estimate is just that. An estimate. It could be wrong. It could be high or low. Even when it's a fixed-price quote, it still carries the risk of being wrong. And while we'd LIKE estimates to come with an assurance of a certain accuracy, there will always be the possibility that something will reveal the work to be more difficult than originally envisioned. Usually, but not always, this is some hidden requirement. The more precise the requirements are, the better the estimation will be, so when an estimator comes back and asks for clarification of the requirements, you as a  PM should jump at the opportunity to clarify those points.
  2. Likewise, if your estimator comes back and tells you that you missed some necessary requirements, the overwhelming probability is that you missed some necessary requirements. If somebody gave you some "high level" estimate that didn't take these necessary requirements into account, you don't have an option. Throw that out and go with the new information. Because...
  3. Disappointing your customers is only possible if their expectations are not met. If they HAVE measurable expectations in the planning phases of a project, then you probably made premature promises. STOP THAT. If you did it anyway, then disappointing your customer once an estimate is returned may be inevitable. If so, it is far, far better to disappoint them in the planning phases when something can be done about it and meaningful decisions can be made than if you disappoint them at Acceptance Testing, when the only option is failure.
  4. Image by Alex Prolmos
    via Flickr
    1. Necessary requirements that are often missed often
      include such things as regulatory governance and technical necessity. They can't be skipped, and they're not free to implement simply because you forgot about them or didn't know about them. They also include things such as the requirements of previously unidentified stakeholders who can block a project well into the execution phase, after a sizable chunk of the budget has been spent, so that their requirements are inserted into the requirements.
    2. Informing the project owners of these new requirements as early as possible allows them to properly revise the requirements, re-estimate the work, and re-budget. That's not a bad thing. It's how projects are done. Also, it gives them the opportunity choose not to do the project because it will prove to be too expensive or difficult. That's not a bad either, and it's not failure. It's a good decision not to waste resources. Don't mis-cast it as something it's not.
    3. Failure to communicate this new information early results in a project that will never be implemented because it doesn't work due to erroneous assumptions, despite coming in on-time and on-budget, meeting 100% of the requirements.
    4. "Failure is not an option" is the dumbest thing that could ever fall out of the mouth of a project manager. Don't ever say it unless you deliberately intend to sound inexperienced. Failure is always an option. Part of the job of a project manager is to ensure that if the worst happens and something does fail, it does so in a manner that does the least damage. There should always be planning for failsafes. "Failure is not an option" is just an expression used to advertise that you don't want to do the hard work of project management. Always be able to answer the following:
      1. What's our fallback?
      2. Describe the procedure for rollback.
      3. What business processes can work around a problem?
    5. By the way, I realize that some people think that "failure is not an option" is a clever way of saying that you want people to treat the project with importance and work hard. The problem is, it's not clever. Tell the people what you want, clearly. Idioms and clever sayings will only be misunderstood by various members of a multicultural project team.
  5. "Definition of work" is not done in the estimation phase of a software project. That's why you set aside time for Functional Design and Technical Design. What you get at estimation is a very, very high level guess at the areas that need to be changed. Determining exactly how they will be changed requires further planning. You've allotted time for that, so exercise a little patience and define the details in the time reserved for doing it.
  6. A work breakdown structure (WBS) is a method of defining a project's scope. "We're going to change these things", or "we will provide these outputs". It doesn't define how you're going to accomplish that work. It doesn't tell you the detail of the work itself. It doesn't tell you the time required to do it.
  7. Proper scheduling can only be done after the work has been defined and estimated. 
    1. If you've created an implementation schedule before you received your estimates, you're doing it wrong. An estimate is NOT "wrong" if it doesn't fit into your Fantasyland expectation of when you'd like to deliver, or how much you'd like to spend. Insist upon it, and you will only prove that failure is an option. I like to quote Bruce Willis in "Armageddon": "We cannot use your Air Force personnel-only drill time card!" You asked for an estimate; you got an answer. Use it. You can negotiate on specs or deliverables, but in the end the work takes as long as it takes.
    2. You cannot plan for 8 hours of work in an 8-hour day. There are meetings. There are other projects. There is support work. There are holidays and vacations, medical and dental appointments, parent/teacher conferences, etc. This overhead is different for each person, but it always, always, always exists.
    3. When your people bust their butts in order to meet an unreasonably tight schedule, you'd be wise to show some tangible appreciation. They are going to remember their effort, and if you don't, you can expect that's the last time you'll ever receive it.
Many of these issues... scheduling, disappointing your customers, etc.... come purely as a result of failure to patiently do things in the right order. You want to get a schedule and a budget and approval, etc., and so you make some back-of-the-napkin plans before formally defining the scope and requirements and getting estimates from the people who are skilled in delivering the final product. This in itself isn't terrible.

What is terrible is the failure to realize that all of that sort of planning simply represents desires and wishes, and not what can be reasonably delivered. You can demand all day long that these daydreams of the future "must" fall within 30% of a final estimate, but that means exactly nothing when measured against reality. Often you must simply pay more, adjust your requirements, or choose not to do the project at all. The only question is whether you'll do it voluntarily.

Wednesday, April 30, 2014

Happy Birthday, BASIC!

Happy Birthday 
to the 
Beginner's All-purpose Symbolic Instruction Code

Today is the 50th birthday of the BASIC programming language. As promised, I'm celebrating the event by releasing a handful of programs I've written in a dialect of BASIC.

I've chosen to write these in Gambas 3, a dialect that's only available on Linux[*]. But rest assured, you're not missing much. These are prepared for the occasion on short notice, and all are short of having earned a 1.0 release number, though I'd say all but Tablut are pretty feature-complete.

Tablut
First up is "Tablut" (Tablut.tar.gz) a Tafl game. Tafle is a genre of boardgames popular among the Vikings, which eventually died out and is now enjoying a bit of a renaissance using re-created rules, as best as the archaeologists have figured them out. This version of Tablut provides a working two-player board, enforces three scholars' interpretations of the rules, and has the world's absolute worst AI (which really is only there to test turn-based play... I haven't had time to actually write a "real" AI).

TimeTool
Next is TimeTool (TimeTool.tar.gz), which I've previously had as an open-source offering on other platforms. It was previously written in Delphi (Pascal). People have asked me when I would update it and fix some bugs. I suppose I just did, so I may wind up back-porting these changes to VB.net for the Windows crowd. TimeTool is a very odd sort of duck. It keeps track of the projects you're working on, and very pointedly does NOT track multi-tasking. It helps you determine where you've been spending your attention. It keeps accruing time to tasks even when it's not in memory, so it's great for tracking tasks that require re-boots.

So Long Sam
Then there's So Long Sam (SoLongSam.tar.gz), which is in fond remembrance of an old 8-bit game I once typed in from an issue of Compute! magazine. After re-writing it for this event, I went back and dug up the original. It seems I remember the game as having been much better than it was, and as this version aligns with my memory, it's more than a little bit better than the original. I did sort of mis-remember the premise of the original, so we'll call this one "inspired by" instead of a re-write. Your goal is to simply cross a spooky graveyard in the dead of night without bumping into a tombstone and awakening a ghost or zombie.

ZenerCards
Lastly, there's ZenerCards (ZenerCards.tar.gz). This is a little time-waster for people who think they are psychic. It will either definitively prove you ARE or completely convince you that you're NOT. There are three challenges: a PREDICTIVE test, to see if you can foresee the future; a CLAIRVOYANCE test, to see if you can determine that which is hidden in the present; and a TELEPATHY test, so see if you can read (or broadcast) thoughts. My prediction is that whoever you are, and no matter the test, you'll wind up with a score of around 20%... random chance.

I have work and real life and stuff, so I'm a little behind. I've put up quick links. Right now it's just tarballs, but as I have the time I'll put up.rpm or .deb installation packages. As it is you can run off the source once you've got Gambas installed, and executable files are contained in the tarballs.

It's Open Source, of course, of course.



[*] Sorry, Windows users. Gambas 3 only runs in Linux. However, this is a great time to try out Linux for yourself. You can install VirtualBox. Then download an "ISO" image of a Linux install DVD and install it in the virtual machine.

Wednesday, April 09, 2014

BASIC Turns 50

The BASIC programming language is turning 50 years old on April 30, 2014. Dartmouth is preparing to celebrate the day with a series of events on campus. If I lived in the area I'd certainly attend. BASIC has impacted my life in ways more positive than I can relate.
BASIC (Beginners All-purpose Symbolic Instruction Code) is the programming language developed by John Kemeny and Thomas Kurtz that later built Microsoft a programming empire. Versions of the language were included in lieu of operating systems in nearly every microcomputer in the 1980s. The language was later expanded, expounded upon, and otherwise improved to add the ability to use objects and events and structured syntax while retaining its simplistic roots.

I've written BASIC programs on and for the following machines: 
  • a timeshare system which I only knew by its terminal 
  • the TRS-80 Model I, II, and III
  • the TRS-80 Color Computer
  • the TI-99/4 and TI-99/4a Home Computers
  • the Commodore VIC-20, Commodore 64, Commodore Plus 4, and Commodore 128 computers 
  • the Atari 400 and Atari 800XL
  • the Apple II family
  • the IBM PC, in the following dialects:
    • Asic ("almost BASIC", a really awesome little DOS native compiler)
    • GWBASIC
    • QuickBASIC and QBASIC
    • Visual Basic
    • Visual Basic for Applications (VBA)
    • VB.NET
    • LotusScript (Yes, the primary language of Lotus Notes is a BASIC dialect)
  • for Linux in the following dialects:
    • FreeBASIC
    • Gambas
  • I've also had a few calculators (Casio and TI) that used BASIC as their programming language.
Gambas! (click)
Of the modern variants, I do like Gambas best, and make a decent living writing in LotusScript, and the various Visual Basics.

Haters Gonna Hate

BASIC is a language that it's very fashionable to hate.

Edsger W. Dijkstra famously said, "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Meh. That's a snobbish attitude of the sort that would deride Captain Kirk for splitting his infinitives.

Besides, the criticism is largely obsolete. It's completely possible to write "good" code as defined by computer science snobs. Keep in mind, though, that "good" code isn't always defined by how elegant it is, or how "supportable", or how it conforms to one man's idea of mathematical purity and logical rigor. Often a task needs to be done, quickly, with a minimum of fuss and effort. A "good" program is one that does the job. Often, a few lines of procedural code will suffice to replace a rather complicated object-oriented affair, most of which exists to do nothing but frame the procedure that never required an object in the first place. A good modern Basic (like Gambas) does both, and you get to choose.

In truth, just as the freedom of English produces better poetry than the strictures of Latin, there is chaotic beauty in BASIC that isn't appreciated by coding purists who walk around as if they had punch cards up their butts that they're not allowed to fold, spindle, or mutilate. So beat up on BASIC all you like. Then we can talk about how fat your momma is, just to raise the maturity level of the conversation. ;)

Presents for All!

I think a really good idea for BASIC's birthday is to give away some free programs, written in BASIC. So I'll be doing that. On April 30 I'll release a program written in Gambas. Don't expect too much... it'll just be a nice little program that'll keep you clicking for a little while. You'll be able to tear it apart, look at the source code, see how an event-driven Gambas program works, etc.

Happy Birthday, BASIC!