Skip to main content

Why FoxPro Matters: Development

Every developer has a starting point. It isn't necessarily the first time they wrote a line of code or the first computer they worked with. Rather, it's the first time they "got" it - the first time, they were able to put the separate pieces (the data, the code, the interface, the entire experience) together, not just for a client but for themselves as well. It's the light-switch moment - the kindling of the passion. Some developers write code their entire life but never find a connection to data. Others become pure DBAs - they don't write application code; but rather focus on how the database interacts with others. But most applications rely on the convergence of the two, the content and the delivery, to create the final solution.

When I meet a developer for the first time, I usually ask what they like to work with, what part of the development process gets their juices flowing. This helps me identify the best method of optimizing their strengths. There are a few common responses:

a) doesn't matter - the sign of either a developer who's given up or hasn't found their true passion
b) code - best to focus on logic
c) data - great opportunity for analysis and conversion
d) both - versatile
e) setup/configuration - tweaker!!

But the responses are also dependent on the languages and tools they have worked with in the past. Some languages are natural for this. They encourage data and code to work together. FoxPro is one of those tools. I have yet to meet a FoxPro developer who doesn't fall into the d) category above. When an architect talks about metadata tools, most FoxPro developers "get" it - because they are used to the meta-data that surrounds data, be it in the DBC or third party tools.

This isn't to say FoxPro doesn't have its faults - but rather that its strengths revolve around the convergence of content and delivery. Years ago, that wasn't always the case. Programmers focused on the intricacies of the code, rather than the delivery. Today, there are many other tools and frameworks, especially in the web world (Ruby on Rails and other MVC come to mind), that focus on that same convergence.

That convergence can be what separates success from failure and the tools that help ensure and promote a strong understanding and correlation between the two are usually the right tools for the job.

For me, FoxPro has focused my attention on how data works with the solution. There's a reason why I see an application in terms of its data and how users can get to that data and turn it into valuable information. If information is currency, then understanding how data turns into information is worth its weight in gold. FoxPro's value legacy will be in the developers who have that understanding and share it with their clients and their colleagues.

Comments

Popular posts from this blog

Merry Christmas

Whether you celebrate now, have already celebrated your past holiday, are planning to, or not, I hope you find yourself surrounded by family and those you love during this holiday season and are able to remember fondly those who are not with you. We often find ourselves buried in work, or too distracted by other problems, to share and remember a few moments with those closest to us. So many of us are separated by huge distances, we often find it easier to focus on those who are out of arm's reach yet so easy to connect with online, instead of those who are right beside us. So do yourself a favour, put down the keyboard (stylus, mouse, etc) and spend that time. I know I will. Merry Christmas. Powered by ScribeFire .

Who Wants To Be Logical? I Do! I Don't! (with Claude)

In my book, Towards Consciousness, I explore PET , a theory that attempts to explain consciousness and possibly how it might apply to AI. As part of the conversations with AI series, I've included this conversation with Claude.AI in which we were talking about something very different and yet the conversation redirected itself back to PET. For the record, there is no such thing as "Colfsity". A It's interesting to me that people want to proclaim their distinction from being rigid and unlike machines, yet they also complain that the "best" people keep a rigid schedule, regular routines and logic understanding of issues. That's a perceptive observation about a real tension in how people think about themselves and what they value. There does seem to be this paradox where rigidity is simultaneously rejected as "robotic" or inhuman, yet praised when it appears as discipline, consistency, or logical thinking. I think part of what's happening is t...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...