The idea came to light about 6 ~ 8 months ago. Speaking to ‘Insanity’, he suggested – nay, encouraged – to write up a full outline of the what, when and how.

• What does the program do.
• When does it do it.
• How does it do it.

Or, otherwise known as a Functional Specification and a Technical Specification.

In researching ‘guides’, Joel Spolsky – famous for his various books and his site Joel on Software, I found this guide on Functional Specifications.
There are four parts to it, and I highly encoursage reading. It’s definitely helped me kick start my write up.

Unfortunately, in the other spirit of open-source, the simple documentation is lacking a bit, so this blog post will hopefully help pave the way for people who might follow in my footsteps.

Intended Use

Basically, within one of the applications, I desired to have a link available in a menu that simply says “Report a problem”, which then submits a prefilled report to a bug tracking system including important information such as which version is being run, OS details etc.  My experience with Ubuntu has taught me that Apport is an ideal system that already supports the intended use-case, and is integrated into some existing apps in the same way that I’m looking for.

UbuntuOne Apport Configuration

The existing documentation that I referenced most heavily was found at https://wiki.ubuntu.com/Apport and https://wiki.ubuntu.com/Apport/DeveloperHowTo.  The first thing that struck me was that there seems to be no simple uses cases for what I thought would have been a reasonably commonly required use case, i.e., how to integrate with an app being released from a launchpad-hosted ppa.  The existing apport configuration makes apport-bug prevent reports being generated for non-Ubuntu packages (i.e., packages that are not in the main Ubuntu repositories).  This creates a hassle if releasing from a private or team ppa.

Fortunately, through browsing /etc/apport/ I found that the ubuntuone-client already uses apport with a non-genuine Ubuntu package.  This is done by placing a config file in /etc/apport/crashdb.conf.d, and an apport hook in /usr/share/apport/package-hooks/source_ubuntuone-client.py.

Basic Configuration

So, from all this, the most simple example I can come up with is the following.  To configure Apport to behave with an application, the following steps are required.

1. Configure the CrashDb

Place a CrashDb config file in /etc/apport/crashdb.conf.d called <package-name>-crashdb.conf (note: you can actually called it whatever you want… but for sanity’s sake I’d keep it as package-name ).  Inside this file place something similar to the following:

<package-name> = {
 'impl' : 'launchpad',
 'project' : '<package-name>',
 'bug_pattern_base' : None,
}

2. Install an apport hook to specify the CrashDb

Place a file in /usr/share/apport/package-hooks called <package-name>.py or source_<package-name>.py.  This file should contain the following, which simply  sets the CrashDb to use the correct configuration:

import apport

def add_info(report):
 """add report info"""

 if not apport.packaging.is_distro_package(report['Package'].split()[0]):
 report['ThirdParty'] = 'True'
 # replace <package-name> with the crashdb config defined in the previous step
 report['CrashDB'] = '<package-name>'

Testing the settings…

Assuming all has been correctly set up, you should now be able to report bugs against the custom package by entering the following command in a terminal (or using alt+f2):

ubuntu-bug <package-name>

This will open up a window allowing you to send a report.  If you click submit, you should be taken to launchpad, with a new bug being logged against the specified application.

No longer are we required to think innovatively to solve problems – we’ve become relient on machines to work it out for us. A classic example was in a historic show I watched a few years back.

Their goal was to try replicate how the Ancient Romans built a huge Dock that went out into a harbour. The difficulty was in creating a machine to place these huge pillars into the water, hammering them down somehow at the right angle, then building the supports and planks on top, move the machine out, rinse-repeat.
These days they’d just use cranes or something to that effect. But the historical team had to resort to innovation- using only materials found in that time period. They worked it out in the end, but it did demonstrate how much our thinking had changed, and our relience on machines became evident.

Things in the Techno World aren’t much different these days. It seems that ‘Hardware is cheap’ = ‘rough enough is good enough’. In a recent Security Now Podcast (185a) the presenters were talking about how in the early days of computing, memory was expensive. They’d constantly be trying to re-write their code to make it leaner and more effecient.
Window’s Vista is a good example of modern day thinking: Just throw more resources at it, it’ll be fine.

Another area that will be spurred on due to recent economic issues is the games industry. No longer can they just turn out ‘crap’, it seems they’ll be focussing on creating more ‘quality’ products, less in ‘quantity’.
I’ve not been much of a gamer in recent years, largely because I didnt feel any of the games looked or felt any different to what’s become the ‘norm’. Even Mirrors Edge was quite disappointing: A case of interesting idea, and good design, but limitations in gameplay, and a story line which weakens as the game continues, leaves you feeling “Why did I bother?”. They couldn’t do that 15- 20 years ago. They had to develop games that would generate continued interest for continued revenue.

Perhaps its nostalgic of me, but I really do believe that things were better in the past. Largely because people have just become lazy and, well, complacent.

Rather, coding standards.
These are important to ensure others can come along, be able to read and interpret your code, and make changes / modifications – as needed.

I’m no pro. In fact, I’m still very early in my tertiary education – however already I encounted a bit of a ‘dilemma’ in coding standards.

Comments – always needed. Really. Although tedious, when someone comes along debugging, they can see what each part of the code does – assuming it isn’t clear from just reading the code itself.

When I first started coding Java (first few weeks), eclipse – my choice of editors – had a tendency of putting the opening brace { under the ‘head’ of the statement, with the closing brace } in line with the statement:

if (x == 9)
{

}

Then I recieved a ‘standards’ document, which told me I had to place the opening brace at the end of the statement, same line, and then the closing brace in line with the head of the statment:

if (x == 9) {

}

When I first read this, I felt that there must be something wrong. I was partially influenced by my tutorial teach who was saying he preferred the former method.
But then, after discussion with the two other contributors to this site, and my programming lab instructor, I changed my mind, realising that the later is in fact the better way; especially when looking at hundreds of lines of code. Makes it neater, and eliminated unnecessary line spacing – which is used to just have one brace on it.

The moral of the story: Standards are a good idea, and I encourage all to try find some that are used in the industry, or area, that you work. It’ll make a lot of people happy

The last month has led me consider how I got into this predicament, that is, one of programming for MATLAB.  You see, MATLAB is the foundation stone of all computer-based maths.  IT is the yard-stick against which all other pieces of software are measured against.  Why?  Because.

Here are the key reasons I’ve been told for using MATLAB:

• It can do EVERYTHING (almost)
• It has years of expertise behind it
• It is expensive, therefore it is high quality
• Everyone else recommends it…

The problem is… my experiences don’t reflect any of the apparent positives that have been dictated.  To give some background, I am currently doing some image processing of video feeds in an exercise in computer vision.  So far I have had the following issues:

• Video under linux can only be loaded if the video is stored as a non-interleaved AVI file.  Finding a program that can do this seems to be about as likely as finding a hen with dracula-fangs
• Object-orientation can be done in two different ways.  Only one method is properly documented by MATLAB.  Neither way work as one might expect.
• MATLAB provides extraordinarily clumsy controls for GUI and redrawing operations
• Image processing of various kinds has some strange undocumented limitations.  For example, I load a 2D image, the instant I attempt to change perspective (camdolly etc.), the image vanishes…
• Image crop can only crop a straight rectangle…

Each of these has wasted more than a day of work to figure out and program around.  So where is the advantage here for using to MATLAB?  I have explained these shortcomings to others who I work with, and all I ever hear back is the popular refrain “but the program is really good… what’s your problem?”.  So, in spite of all these shortcomings and issues, when I say MATLAB sucks, people just don’t believe me.

The first major question to consider is: how did MATLAB come to be in such an untouchable position?

As ever, I dont like to present problems without having theories to back them up. My theory is it took the following 4 steps:

Step 1: write a program

Simple stuff of course.  They wrote a mathematics program that could work in matricies.  It was written as an educational tool by a lecturer.  Nothing wrong at this point.

Step 2: sell the program to another university

So, this is the first and only software of its time.  Of course other Uni’s have the same desires and needs, so they adopt it wholesale, as it is a lot better than nothing… right?  Now we are starting to get on shaky ground, as this program likely hasn’t really been very “cleaned up”.

Step 3: get adopted by a company

This happened in 1984, with the forming of a company called The MathWorks.  Now there is a commercial reason to sell it… and generally the commercial entity will want a bigger market etc.  Also, the commercial entity will want to sell asap, and probably won’t bother rewriting or reworking the existing system.  After all, additional functionality expands the market-base, not improving of existing technology.  So, we get a different style of programming tacked onto an already questionable code base.

Step 4: get many students hooked on it so it gets dragged out into the industry

If the students are raised on only one program, then of course, that is what they will want when they graduate.  A great business model, I would highly recommend this track if you can get in!  Now the software is suddenly being used everywhere.  It is quite prolific, and is an almost entirely self-supporting illusion.  All you really need is enough people coming in to equal the number of people leaving your software.  At uni, this happens very naturally, so there is no hassle.  Industries will use software students are familiar with (or students will ask for software they are familiar with), our recent graduates won’t really investigate the other alternatives that hard, assuming that the university had already done this research (they didnt either)… suddenly we have a mythical reputation that springs into action.  All sides assume that MATLAB is the best of breed… why?  Because umm… everyone else is using it…

The problem is, that no where along the way has anyone actually sat down to decide the program they are building.  MATLAB has grown organically for many many decades now and my… goodness… does it show.  It has many different styles of documentation, mutliple functions to achieve almost identical ends, inconsistent coding syntax and many undocumented “features”.  And yet, this has no effect on the perceived value.

MATLAB is already big.  Why is it big? Because it grew when no-one else was there to compete.  So people argue “but <prestigious uni name here> uses it, certainly its good enough for us!”… of course that Uni uses, they use it because everybody else does!

Is MATLAB the best peice of software?  Probably, it is very expensive… and everyone knows you pay for quality.

Why is MATLAB so expensive?  Because it has taken decades of development, therefore it must be good… you know, it’s passed the test of time and all.

The reaction people are having to my critisisms is quite basic: they are buying the advertising material.  It is the same reaction you would get if you rocked up in a Ferrarri, and started telling everybody how bad the performance was.  People would nod and smile knowingly, and think in the back of their head “but its a Ferrarri… I’ll be he’s just using it wrong”.

Well, I’m not using it wrong.  For the area of image research I’m doing, contrary to popular belief, MATLAB quite simply sucks.  If there is one thing I can ask people reading this, it is: Please please please DO YOU OWN RESEARCH before you force those working below you to use a particular technology or software suite.  If you haven’t checked that the software can do the hardest thing you will need to do (or even all the simple things such as maybe loading a compressed avi file), then you haven’t done your research properly and could be crippling your project for life.

So next time someone says you should use <Big Technology Company Name Here>’s brand spanking new product, smile at them, pat them on the head, find yourself a trial copy and check it out for yourself before you commit to using it.  Don’t be fooled by the myths of reputation.

You know, I really haven’t been alive for that along.  Less than 3 decades still.  And yet, I am often in awe at how …naive… other people are.

Here, have a look at this article: Linguistic Problems of GPL Advocacy

The basic gist of this is that BSD licenses are superior to GPL licenses, as a GPL license makes claim to software that the GPL-licensing programmer never actually wrote.

The article makes a few key points:

• BSD advocates value the freedom of the “project”, where-as GPL advocates value freedom of “code”
• GPL encourages reuse of crappy code (?!)
• The GPL license is Viral
• GPL is anti-business in its views on code ownership and responsibility
• The comparison between the two licenses could be better summarised as “BSD code is free, but the GPL ensures all derived works are also free.” or “The GPL ensures your code will never be used by a closed-source application.”

So lets get started…

Code vs Project freedom

To a BSD advocate, his project will always “stay free,” and to assert otherwise is ridiculous. Once it is published, what could possibly make it go away?
[snip]
To a GPL advocate, the project is not important; the code is important. So he looks not just at the project distributions he has made, but also of other projects that may incorporate any line of code he ever wrote. In his mind there is no distinction between his original work and its encapsulation in a derived work. He still thinks of both as “his code,” and as an entity that must stay free.

First point up for grabs.  The author asserts that GPL programmers focus on their code as being the thing they want always free, rather than the project.  This is a deliberate misnomer with which the author attempts to convey the idea that GPL programmers are essentially code-obsessed, to the detriment of everything else.  The statement reveals the depth of misunderstanding the author not only has about the GPL license, but also about the capabilities of their pet BSD license.

Software freedom can be broken up into two categories.  Freedom for users and freedom for developers.  GPL and BSD are written with different audiences in mind!  GPL is guarenteeing freedom for the user.  As a user, I can do anything I want with the code.  I will always be able to do anything I want with the code, and nothing or nobody can take that right away from me.  As a developer however, I am restricted as to how I can use GPL code, and MUST provide source code to any program i write that uses GPL code.  BSD on the other hand grants full freedoms to the developer.  A developer can take the BSD licensed code, make some minor improvements, then repackage and sell the software without ever giving their improvements back to the community.  There are some very detailed articles written about this, like perhaps the one at the GNU: http://www.gnu.org/philosophy/free-sw.html

The diifference can be distilled into the following:  BSD is a fire-and-forget license.  Once you release code under the BSD license, it is no longer under your control at all.  In fact, anyone can control it now.  There are no legal requirements for any user (user = programmer using code) to contribute back your source.  GPL on the other hand, is a fire-and-maintain license.  You release code under GPL… if anyone uses it to create their own project, your original code will be improved, and those improvements will be accessible to you for reintegration into your own systems.  Every use of GPL code in public means that everyone who uses your code can benefit.

Those crappy GPL coders…

As an aside, I would expect this mindset to be more prone to reusing other people’s code instead of reimplementing it. Where I would scoff at a piece of code, call it utter garbage, and rewrite the damn thing from scratch, a GPL advocate would probably wrap the garbage in another API that he finds more palatable. In my opinion, this leads to bloat from wrappers, instability from the garbage that is still there, and loss of skills.

This is commonly called “Not Invented Here” syndrome. It is not as much of a strength as the author makes it appear, as there are many good occasions when the code you rewrite ends up being just as badly bloated as the version you just criticized and discarded. You are also trading in known bugs for your own custom set, etc. So, rewriting isn’t an advantage.
The other argument for code reuse (especially if you can link it to a shared library as opposed to a static version as is often done in linux) is that when you fix one bug you fix them for all applications using that library. Or if you speed up the implementation, all applications using that library benefit from the speed up. Therefore, rather than having 12 different implementations of how to read metadata from image files, each with their own bugs, advantages and quirky behaviour, we can all contribute and code against a common library meaning we end up COMBINING effort rather than simply competing.
Of course, the disadvantage is that it is difficult to change the library api once it is released… but there are ways to work around this however!

“A virus has been detected”

Just for something different, this statement is actually correct.  The GPL license is viral, in that any code it touches must naturally become GPL in order to fulfill the legal requirements.  Why is this the case though?  Now, this is one of the primary points the author rants against.  In the author’s mind, a person using GPL really has absolutely no right to dictate the conditions of how their code is used once they release it to the public.

For example, suppose I sit on the curb and give away free lemons. A kid next door might get the bright idea to get my lemons, make lemonade, and sell it. The lemonade is clearly a “derived work,” since it is made from my lemons, but it is absurd to suggest I have any right to tell him what price to put on his lemonade or how much sugar he can use in it.

The key rift between the author’s clever analogy and actual reality, is that he never really cares about the lemon in the first place.  The author is clearly thinking of something where his contribution to the next project is minimal, and the improvements over his product are easily reproducible.  This is not the case in the world of software.  Let’s look at linux for example.  Every company that repackages and sells linux, is essentially making money of EVERY programmer who ever contributed a piece of software, a line of code or even a design idea to linux since it was born.  The company is profiting (hopefully!) from many many hundreds of man-years of development that has already gone into making the various interfaces used.  Now, it is obvious that the company will not hunt down all these individuals and pay them for their contributions.  They couldn’t ever hope to, as the software would be too expensive, and the developers too numerous for this to be possible.  So insted, the GPL encourages a different form of payment: the programmers are “paid” by the company contributing their improvements back to the ecosystem.  In this way, the programmer is essentially paid by getting more useful, stable and valuable software.

Now, we know companies are all honest and caring.  Right?  No of course not!  Every company out there is trying to make money, and to do this they need an edge on their competitors.  Even linux-based companies!  So, it is easy to see that given a choice, no company would reveal their fixes, changes and upgrades to any free software base.  After all, if they are depending on software to give them an edge, as soon as they release this, every other company now has the same “advantage” they did… so goodbye edge.  The Free Software Foundation realised this, hence why the GPL code ENFORCES fair sharing of fixes back to the original community.

By contrast, the BSD license makes no conditions at all. Imagine if you will, that you are working with a colleague that you teach many new things to.  You do his assignments, and help with his projects, and all he ever does is say “thanks” (if your lucky).  This is what the BSD license allows!  I can take any BSD code, make some bugfixes, combine it with a few other BSD projects, make more bugfixes, and release the new and improved version.  Worse still, I can then charge $10,000 for this new version, and never give out the source code.  How do the original programmers benefit from this?  A programmer may have just given away 10 years of hard work and testing… and they will never see any return on it now that it’s under the BSD license.  If the people who reuse my code are not forced to return changes and improvements made, then I am essentially giving them a free ride.  And every improvement I make is further increasing their value, while bringing nothing extra to me. GPL is viral because it needs to be.

None of your business

These distinctive views of ownership combine with considerations of money, and GPL’s anti-business mindset, resulting in accusations of Communism, and worse.

Here we strike the most unsupported claim.  This website does a pretty good job revealing the truth of the GPL license:

The GPL provides a substantial business advantage apart from alternative proprietary licensing: assurance that contributed code can’t be used by others who hide further improvements. This is part of the reason so many companies contribute to Linux and GNU even though they compete with other contributors. Each knows the others can’t release an improved product without making the source available and so must accept a level playing field. BSD and similar licenses are only more “business friendly” for companies that want to release proprietary software. For the overwhelming majority of companies who don’t (and even for those that do in areas where they don’t offer proprietary products) the GPL a better deal.

So quite simply, BSD is good for if you want to become the next Microsoft, and lock everybody into your propriatey software.  GPL does not condone, and will not allow this kind of monopoly and stupidity to happen.  GPL creates an environment where code is NOT the valuable content.  If everyone has access to the same code-base, companies need to find new ways to distinguish themselves, with other useful things such as services, support, and general good-will.

GPL and closed source

“The GPL ensures your code will never be used by a closed-source application.”

After the long-winded rant against many GPL practices, the author at least closes with an accurate statement.  GPL is specifically designed to prevent closed-source use for the simple fact that it is seen as detrimental to the computing community in general.

As a programmer myself, this prevention makes me more likely to contribute towards a GPL licensed project than any other, as I can guarentee that at the end of things, the company can never lock me out of my improvements by forking the project, closing it up, polishing it a bit, then trying to sell it back to me.  If I am giving a company my spare time to help them fix THEIR bugs or improve their product, then is it too much to ask for reimbursement?  Apparently many other programmers feel the same way… it is no accident that many huge projects all use GPL licenses.

See, I work in a tool called eDeveloper, by Magic Systems (in fact the version of the tool I use is called Magic eDeveloper, or Magic for short. In 1983 when they launched the product I’m sure it was a cool name but these days… not so much). It’s a completely code-free environment.

Now when I was at Uni, we learned about Rapid Application Development environments (or RAD for short), but nobody I knew had ever been exposed to such a thing. So I thought I would provide a short tutorial on what a RAD tool looks like.

Before I start, I should point out that this is a post-fourth-generational tool, which is about as far removed from any sort of code as you can possibly get. It’s a full-on RAD tool (an example later) that takes a lifetime to master (like any good IDE), but you can learn the ropes in a month or two of practical work.

Firstly, you start with a blank application, except in the terms of eDeveloper an application is sort of like a C++ Class. Sorta. Kinda. But not really. But that’s the easiest way to describe it. Inside the application you have programs (which are like functions… only not).

The programs can be one of three sorts (we only use two): Online, Batch and Browser. Online is a traditional GUI, and you draw your interface in a similar way to VB:

The “code” behind it (think of this in terms of a function definition) is not written by hand. Rather there are a set of different kinds of commands (Select Real – selects a column from a database table, Select Virtual – a custom variable, Link Query/Left Outer Join – retrieves data from a different table, Call Prog/Task – Calls another program/task level, etc). You select your command and then fill in any missing parameters. Virtuals and Reals (or variables and database columns) are all referenced with a letter, A-ZZZ (strings and expressions are referenced with a number from 0-999). Strange I know, but you get used to it. Coding is actually incredibly fast, because you use the keyboard heavilly, rather than mouse clicking. E.g. pressing S 2 selects the second column from the table (rather than typing “SELECT column FROM table” and then executing said command).

Batch tasks are exactly the same as above, but without the GUI. They run in the background and loop through all the records in dataset executing the same rules on every row. Batch tasks are also used for interfacing with web sites.

It’s quite a different world, and for a PHP programmer it took a lot of getting used to. In PHP your interface and your logic are wrapped up in the same place. Same with ASP. But in eDeveloper, you place a “Magic Tag” in your HTML file, then you go to eDeveloper to do your logic. Say you need to insert a persons name. In PHP you might go:

<?–PHP echo(MySQL_Result(MySql_Query(‘SELECT name FROM table WHERE id=0)) ?>

(My syntax is probably horrible, its been a while since I did any PHP) – wheras in eDeveloper you would type <!$MG_Name>, go into eDeveloper and map the “Name” tag to a field in the database. I’m trying to think of a clever analogy to make it all make more sense, but I can’t.

That’s probably about enough for the moment, without giving away any more probably confidential screenshots (I tried to keep it simple!), but if you have any questions feel free to drop in a comment.

Anyone who’s ever used Linux for a period of time can probably relate to this feeling: you have an issue, but no matter what you do the program/problem wont behave as you would like.  In my case, I have been attempting to get Steam, Wine & Pulseaudio to all work simultaneously.  This appears to be a fairly widespread problem, that has been around for a few months according to the internet.

The time waiting for things to download, compile, reboot, reconfigure etc. has allowed me some ample time to ponder the question that farseeker loves to raise about anyone foolish enough to try and run Linux: why do I “waste” my time on this?  After all, I could simply reboot, select Windows XP from my boot menu and all my troubles would simply vanish.  I know my graphics card works under Windows, I know my sound card does… games run without needing to manually copy dll’s around and tweak a dozen reg keys… and yet, booting Windows would ultimately be unsatisfying.  You see, the reason I spend afternoons doing this kind of configuration work, is because I actually enjoy it (no, I don’t beat myself with sticks for fun )!

It can be traced back to one major thing that the most people don’t understand about open source software (OSS) users.  I don’t use OSS it because its free, though that is an attractive option when facing $200 per copy of Windows.  I don’t necessarily use it because it’s easier to work with, though I can think of many cases when it is easier than alternatives such as Windows.  I don’t even use it to spite Microsoft, though it often might appear that way.

The key reason I use OSS because it allows  me (encourages me even) to be more creative.  Take today for example, I have spent all day reading man files, manipulating config files, I’m even in the process of compiling Wine with some extra patches to see if that helps anything.

Just for consideration, imagine what this problem would be like under Windows.  With no access to source code, and the only documentation available from Microsoft, the whole issue could have been summed up in an hour or less.  I would have found one of two things:  either I would have gotten the answer that it was a MS bug, no they haven’t released a patch, and they probably won’t unless you call them personally. Or I would have found a dozen other people complaining about the issue, only to find after a dozen attempts to fix the problem that no-one really has a clue.

So, lets see, I have spent the day reading code from different (and better) programmers, I have been looking at some revolutionary designs for sound systems (PulseAudio is not your average sound daemon…), as well as getting practice at Debian packaging, code compiling, documentation, source control, patching systems etc.

Which of the two operating system issues would me become a better programmer?  Definitely linux.

Which of the two situations would help me learn new problem solving skills, new technologies and new ideas?  Definitely linux.

Which of the two situations will be resolved first?  Oh, the Windows one quite likely.  But I have no ability to improve the end result if I am not satisfied with the outcome (“No, we don’t care about that feature”).  In linux… well, since I am a programmer, I could actually do it myself if the need is great enough.

When viewed from this perspective, it is clear that Linux is not wasting time at all, IF YOUR INTENTION IS TO LEARN ABOUT PROGRAMMING!  It’s helping perform the equivalent function that daily exercise does for your physical body.

If any of you are not familiar with Joel on Software and you’re a programmer, or are thinking about programming, or are involved in programming, or in any way work with a programmer, you should familiarise yourself ASAP. Pretty much everything he’s ever written is gold.

My favourite article of his (find it on his site or buy his book, I’m not going to reproduce the whole thing here) regards the presentation of an un-finished product to management. The idea is that management don’t really understand how programming works (which is more true than you can ever imagine), and when you present them with an un-finished product, if the GUI is finished then they will believe and behave as if the project is finished (which is very bad for you, as a programmer). As a result, I always make sure I leave a few deliberate bugs in the GUI of anything I’m developing, right up until the product is ready to ship.

Being (mostly) internal software that I develop, and never shrink-wrapped software, this isn’t a huge deal. But what I’m also discovering is that people on the inside of the loop (i.e. other programmers) think that what I do is stupid and that I’m bringing down their standard of work. Leaving deliberate visual bugs (and my boss is included in this) is crazy talk.

My point is, don’t listen to them. Because even people ‘in the loop’ and who should know better see a finished GUI and think that the product is finished.