Developing FileMaker™ has, for me, been a 33 year obsession/passion and along the way I’ve made every mistake in the book, and sometimes I still do. But over the years I’ve also learnt a lot, especially in recognizing what my skills and abilities are and are not.

I am, unashamedly, a FileMaker purist. What that means is that I try to use native FileMaker functionality as far as possible. But what do I mean by native FileMaker functionality?

To me, most of the newer technoligies that are now in FileMaker (APIs, JavaScript, Execute SQL, etc) are not native. Of course they are, but they require a different skill set to usng FileMaker in the way that it was designed to be used.

Yes, there are some really clever people who’ve embraced and mastered these ‘modern’ technologies. I’m not one of them and here’s why. I’m just not interested in learning them and if there is a pressing need, and I mean pressing need, for them in a solution I’m developing, then I hire an expert to do it.

Now, it’s not that I’m incapable of learning new things. I’m currently learning Spanish and absorbing it at an astonishing rate. Yes, okay, I have linguistic abilities but, even so, my progress surprises me. So, what’s the difference between learning how to speak Spanish or write an API? Easy. I want to learn Spanish.

You can call me a dinosaur if you want; that’s ok.

I also think that too many people coming into the FileMaker world rely too heavily on the technologies they know well, and, because of that, don’t ever get to discover how enormously powerful FileMaker is. They are missing out.

Almost every old-time developer that I know, and by old-time I mean those who’ve been developing FileMaker solutions for more than 20 years, stumbled upon FileMaker and fell in love with it too such an extent that they changed careers to work in it. It let’s us be creative, innovative and make money from being so, but, fundamentally, it was, and is, fun to work with. Even after 33 years, it still is.

If you’re a listener of Fireside FileMaker; the podcast I co-host with John Mark Osborne, you’ll already know how we feel about the above. That podcast started as a result of my first conversation with Jaymo (as he is known to a lot of people). We had put an hour aside to talk but the conversation went on for well over 2 hours. After we had hung up, I couldn’t stop thinking about the chat which had been the most fascinating talk I’d had about FileMaker in years. I called him back and suggested we did it as a podcast and the rest is history.

As I write this, we are coming up to 2 years with 43 episode and quickly approaching 40,000 downloads with some of the biggest names in the community as guests. What is really surprising though is the huge number of rave reviews we receive from listeners. This is in a time where nobody has the time or interest in doing such things.

Like many people, I publish a lot of content (blog articles, video tutorials, etc.) and often feel that it is sucked into a black hole of indifference but then, all of a sudden, somebody writes and say how much they liked it and those small words of encouragement make all the difference. Five or so years ago, I was at a DevCon in Las Vegas and, as I was walking the halls, two people who I didn’t know, stopped me to tell me how much they had liked my 1st book, FileMaker & Me. Those interactions absolutely made my day.

On this page, I’m going to talk about the fundamental principles of development that I try to live by. Some of them are difficult and require a whole lot of discipline but all of them are, in my opinion, worth persevering with.

Now, if you’re one of those people who believe that FileMaker is an inferior tool, and that the newer technologies are better, you should stop reading because it will all fall on deaf ears, but I’m not writing it for them. I’m writing it for you.

Anyway, that’s enough with the philosophizing and let’s get on with it.

The #1 skill that any developer has to have is the ability to solve problems. They are what clients have and why they are coming to you. Don’t ever forget that.

If you want to discover the real problems that your clients are facing, ask them

The answer you get to this question will often be

because we’ve always done it this way

Sorry, but that’s not a reason, it’s an excuse and if they don’t a good reaon, they should stop doing it immediately.

Many years ago, I had a long-term client who hired a new CFO. He demanded that I have the system generate a daily report of all the sales the company made. I said No. An argument ensued with me saying that he wouldn’t have time to read a 350 page report and all he needed was a 2 page summary. Eventually he stormed off in a rage and went to his boss who told him that he wasn’t being paid to waste either of our time. It pays to say No, some times.

When we are brought in to develop a solution for a company, we often face resistance from the workers who think that we are there to eliminate their jobs. This couldn’t be further from the truth, but it is hard to convince them of that fact. What we are there to do is make the company more efficient and them more productive which will make their job more enjoyable because they won’t have to do the things that drive them the most nuts.

The caveat, of course, is that some people will lose their jobs but they will be the ones who shouldn’t have them in the first place or who are fundamentally lazy and just turn up to collect a paycheck. Those people are already resented by their co-workers and won’t be missed one bit.

The Relationship Graph can get incredibly messy and I sometimes wonder if this is a deliberate strategy on the part of some developers who don’t want to be replaced. Below is a mess of all messes that I inherited.

Before I could even start fixing the hundreds of bad programming decisons that had been made in its development, I had to spend 6 hours, painstakingly re-organizing the graph.  Fortunately the client understood and was willing to pay for that time but no client should have to bear that burden.

Of all the advice I can give you, this is the most important by far. Keeping things simple makes it easier to debug and for somebody else to see what you are doing. Yes, it takes longer because you almost always have to go through complexity before you get to simplicity. What that means is that you solve the problem first and then figure out how to simplify that solution.

To put this into perspective, many years ago I lived in Costa Rica and I made a short 15 minute video about Costa Rica. I showed it to a good friend of mine Chris Manton, (who was, to my mind, the best interface designer in the world and who sadly passed away from cancer in 2016), who in a previous career had been a TV producer. He said ‘It’s great but it’s 3 times too long.’ I edited it down to 5 minutes and showed it to him again and guess what, he said exactly the same thing as before. (That video ended up being 90 seconds long and it was perfect).

Take the time and make the effort. It’s absolutely worth it.

No matter how much you study, the only way you are going to get really good at FileMaker is by noodling with it, trying things out and seeing what works and what doesn’t. You have to keep asking yourself What if …

Trial & Error is an essential part of learning FileMaker. Embrace it and have fun with it. (If you can’t do that, you should, perhaps, find another profession).

If you remember that we learn nothing from success and everything from failure, you are already well on your way to being successful.

Scripting is, perhaps, the most powerful part of FileMaker but you have to be very careful to not let all that power go to your head. To give you an example,  several years ago, I was brought in to complete a project that had been going nowhere. (The original developer was, to put it mildly, very resistant).

There was one particular script that seemed to be causing the problem so I started running it with the debugger on. After it had called 10 subscripts and had more than 200 steps without reaching  completion, I stopped debugging and started from scratch. Several hours later and one short script later, the problem was solved. The point of this story is not that the developer didn’t know what he was doing (he didn’t, by the way but was convinced that he wa an expert because he had passed the certification exam!), but that he had made the script so complicated that it was impossible to fix.

It all comes back to KISS

You must always develop from the user’s point of view; not yours. What this means is that you must put yourself in their shoes and realize they are unlikely to have your expertise and that what you see as simple, could be immensely complicated to them.

I’ve often said that every developer needs a completely, computer illiterate person as a friend, and should use that person to test eveything as they develop it.  If they can’t figure something out, go back to the drawing board because you’ve failed.

It all comes back to KISS

Sometimes a client wants something that you know, in your heart with all your experience and expertise, is a bad idea, a really bad idea. It is your responsibility to say No, no matter what the consequences and that may be that you don’t get the job or get fired. You should always be able to back up and explain your position but you are doing the client a grave disservice if  you just say Yes.

You’re not a doormat; you’re an expert and must behave like one.

The other side of the coin is that if you agree to do it. It’s likely to not work out and you may get fired anyway. Also bear in mind that if you have a client who won’t listen to you, then you are already on a hiding to nothing and that’s a client/job you probably don’t want.

Tell clients what they need to hear, not what they want to hear. It’s important.

You are approached by a potential client who has a solution developed many years ago and they finally decide that its time to upgrade it, but what they want you to do is just convert it to the current version. If it is more than 5 years old, I flatly refuse to do it but I give them a reason that they will understand.  I say to them.

“I want you to think of your solution as a Model T Ford. It gets you where you want to go but it’s slow, uncomfortable and fairly unreliable. You want it to be a Ferrari, right?” At which point, they nod their head in agreement and you continue.

“Ok,  I can make it look like a Ferrari but it’s still going to drive like a Model T Ford. You want a Ferrari; you’re going to have to pay for a Ferrari.”

At this point, they may well walk away, and if they do, they do. If however, and this happens more often that you might think, they are willing to talk about it, you can explain that converting their solution will likely cost as much as a complete rewrite without benefiting from the advances in the software; that what they have can be used as a roadmap for the functionality they need and that you can save their data. You’re actually saving them money and heartache by not being a Yes man.

Win, win.

In a nutshell, the interface is how the user interacts with the software so it is very important that the user sees a clear path to doing what they have to do with no areas of confusion. In other words it has to make it easy for the user to do their work.

The interface has to appeal to the user in order to make them want to use it. Nobody likes change; not even homeless people who will ask for it but really want folding green. So if you present the user with anything that is ugly or clunky or unintuitive, they will fight and resist using it; sometimes to the point of sabotage.

Think of the interface as the tip of the iceberg; it’s all we see. We know that there is a huge amount under the surface but it doesn’t concern us. Users shouldn’t ever have to worry about what is going on in the background and, if the programmer, has done their job correctly, they won’t even be aware that there are multiple things happening. For example, if the user wants to print an invoice, there is a button there that says Print Invoice. They don’t fneed to know all of the different steps that go into having that happen; they just press the button and hey presto, there is the invoice.

For a long time, there were quite a number of developers who felt that the only important thing was that the program worked well. Being a programmer is a rather geeky profession and a lot of the really geeky are so wrapped in the inner workings of what they are doing that they fail to take into account the most important person — the user.

More and more programmers today are realizing that they can develop beautiful looking solutions with the tools that products, like FileMaker provide. They can create styles and graphics and all such things but here is one overriding principle that you should always have front and foremost in your mind.

If you can give them a WOW factor, they are likely to want to use it.

If they want to use it, they will be willing willing to embrace the learning curve that they have to go through.

One of the things I’m particularly good at (and I can’t take any credit for it) is the ability to think outside the box and come up with solutions to problems that may not be apparent to others. I don’t know if this is something you can learn or is just something that you are born with, which I definitely was.  Another term for it, that seems to have fallen into disuse is lateral thinking. I love lateral thinking puzzles and one of my favorites that you might want to try is this:

There is a knockout singles tennis tournament with 500 players. If you lose a match, you’re knocked out. How many matches have to be played before a winner is declared?

You’ll find the answer at the bottom of the page but don’t look just yet.  Think about it and see if you can come up with the right answer.

All of us live in a box; the size of that box depends on our determination to kick our way out of it. However, when you do, you just find yourself in a bigger box and, again, you smash your way out of it only to find another, bigger box. And so the cycle of life goes on.

Knowing that, should we bother to smash our way out? Why don’t we just stay where we are where it’s safe and secure? The answer is simple. Smash away unless you are one of those mindless drones content with a life of mediocrity who will go to their graves having done nothing whatsoever with their lives.

What an absolute waste!

But how does this relate to FileMaker development?

You either say that it can’t be done or you go ahead and do it. How do you do that? Trial and error and persistence.

It has been my experience that those who say ‘It can’t be done’, often don’t want to do it!

There are a lot of different points of view on this subject, but if you take the point of view that somebody is going to take over from you, then it makes sense to make that transition as easy as possible.

Here’s what I do. Every global field starts with g_; every calculation field starts with a c_; every utility field starts with a u_.

I never have spaces in field names or table occurrences or script names. I use camelCase when I remember and I try very hard to keep field and relationship names short and descriptive. That’s it. Not too elaborate or difficult.

First of all, finding somebody who is willing to actually read a user manual is rarer than rocking horse do-do!

Secondly, they are always going to be out of date.

But if we stop writing user manuals, how do users know what to do?

That’s a great question and here’s the answer. If the programmer has done their job properly, users instinctively know what to do. However, you need to give them something so what I do is make short, very short video tutorials that cover a single aspect and add a link to that video wherever it is likely to be useful.

There is a second big advantage to making video tutorials and that is, when you are making them, you will discover the bugs in the routine. At that point, you pause the video, fix the bug and then carry on. In my opinion, there is no better way to test your solution.

The traditional way to solve this problem is to say that there are 250 matches in the 1st round, 125 in the second making 375 in total. In the 3rd round there are 62 matches + a bye making 63.  Add that to 375 and you get … 

Or you can simply say that there are 500 players and 1 winner so there must be 499 matches.

If you came up with the answer this way, congratulations, you are a lateral thinker

Your job as a developer is to solve the problems that are holding a company back. When you do so, the company will, generally, become more efficient.

When you make a company more efficient

it cannot do anything other than make more money

When you make a company more efficient, you make the employees more productive, which in turn means that

the company makes more money

Whatever money you got paid, pales into insignificance if you did a great job. Ask yourself

Who’s the big winner here?