Thanks for all the fish, Calvin!

Calvin Hsia, Microsoft developer and one-time movie star,  combines two posts into one to note one great tip and one tip of the hat....

1. If you weren't involved with FoxPro in the early 90s, you may think that Microsoft's MVP program was the brainchild of a marketing expert, but in fact, it came from Calvin's listing of the "most verbose people" in Compuserve's FoxPro support forums. The program is now 20 years old, despite cutting VFP out of the program. Way to go, Calvin!

2. Onto the cool tip, when .Net first came out years ago, I was asked to evaluate the conversion of a fairly dynamic VFP application into .Net. One of the biggest roadblocks was how to handle dynamic scripting. We asked around and even .Net experts couldn't come up with an ideal situation. In other applications, I've ended up using pre-compiled DLLs, loading dynamically, to achieve similar results but I've always wanted a better solution.

Calvin's solution? Using CodeDomProvider and the CompileAssemblyFromSource method. There's a little bit of set up (creating methods that return "known values" (strings, booleans, etc) - but otherwise, compile and execute your code on the fly. Genius!

Thanks Calvin - for everything!!


FoxPro VFP

Fwd: Great Post: Realizing Your Potential As a Developer

http://www.aaronstannard.com/post/2013/02/06/10-Reasons-Why-Youe28099re-Failing-to-Realize-Your-Potential-as-a-Developer.aspx

After going through a week where I had to step in and review a developer's testing process before sending it to a tester because the tester kept on finding easy bugs, this post rejuvenated me.

You Know You're Failing to Realize Your Potential as a developer when you:

• Don't Want To Learn
• Don't Want To Commit
• Don't Want To Understand
• Don't Want To Code (Just analyze)
• Don't Want To Ask 
• Don't Want To Show
• Don't Want To Read

Judging Code

Sam Stephenson of 37 Signals wrote this post on December 13th, 2012 - You Are Not Your Code.

I didn't realize he was one of the authors of the Prototype framework or even that he worked at 37 signals (until the bottom of the post). The other point I wanted to make is that I don't think this is specific to "open-source" work either.

"Developers working together to build shared infrastructure: it’s the fundamental tenet of open-source software. Any motivated programmer with an idea and the ability to implement it can solve a common problem, share the solution with the world, and reap the rewards of future improvements by peer review."

It's not just open-source software - it's ANY software. Every product or project you work on typically involves working together, even if it's by simply pitting your own crazy ideas against each other. You solve a problem and then you get reviewed, whether it be by peers, superiors or, far worse, the purchasing public.

When building software, you make trade-offs. On a recent project, we had to move the prototype quickly into production because it was clear that it would take too much time to recreate it from scratch. For another client, work that was supposed to last for four years (while waiting for a new product) has lasted over fifteen. When you look back at your old code, you likely cringe at some decisions were made - but that was then, this is now.

I can feel his pain though  -

"The reality is that Prototype helped lots of people despite its flawed foundation. But its time had come and gone, and I eventually realized it was time to move on.

It was hard not to take Prototype’s failure personally. Critical blog posts felt like a full assault on my values. And seeing friends use other libraries made me feel like my work was a waste."

It's a great read - and as he notes :

"... you are not your code. A critique of your project is not tantamount to a personal attack.... It is simply the result of a regenerative process, driven by an unending desire to improve the status quo."

As I noted above, I don't believe this is exclusive to the open-source world or software. Sure, companies are judged based on their products; but more importantly, they are based on their service to customers. But as individual developers, your code should always be open to criticism, by yourself or by others.

What is an example of a perfect line of code? Is it:

print "Hello World"

(why are you using double quotes, why do I need to say Print, why is it in proper case?)

Hey, Kevin Ragsdale has a series of posts on how ugly FoxPro is --- I would expect that none of the Fox team takes offense to his posts. They created a canvas - what you do with it is your business.

Ayn Rand once said "Judge and prepare to be judged"

It's how you react to that judgement or criticism that shows your character.

Thanks Sam - great post.

A Quick Plug: Whitey Board

Yes, it's a very politically incorrect name but Whitey Board is AWESOME!!!

I purchased two because the office where I'm currently working doesn't give consultants their own white board (and meeting rooms are hard to find).  Who uses white boards anymore? After seeing supposed consultants and business analysts struggle using a SmartBoard or any of those other intelligent white boards AND getting tired of deciphering things on a smaller screen, I needed something anyone could use and didn't need to sit around a computer screen to look at it.

Bonus #1: INEXPENSIVE (24$ - I bought two 2x3)

It came in rolled up tubes and stuck onto the nearby wall in minutes.

Bonus #2: Super easy to put up anywhere

You can unstick and re-stick it anywhere.

Bonus #3: Roll it up and take it with you

If you're looking for a solution for discussing ideas in a group, check it out.

Of course, there are some downsides:

1. The provided dry-erase pen is useless. Buy some better ones.

2. Because it doesn't have edges, you may want to create your own border so that your "drawing" doesn't bleed over to the edge. Lucky for me, the wall I posted it on is easy to clean.

If I had a larger office, I would look at some of their other cool offerings like the Ghost (clear) Whitey board and the large board (4ft x 6ft).

Always Be Releasing: one week iterations

In reviewing older posts, I came across this little gem that had never been posted but is always particularly relevant to development today. I posted a more thorough outline on my process blog. http://intridea.com/posts/always-be-releasing It's a short post but hits on a key point for developers and anyone involved in a project that seems to be going on and on:

I burn out when I'm not releasing.

One of my clients recently started one week iterations.

If you're feeling burnt out, take a step back and think about something you can release this week.

I was asked "do I feel the one week is too short a time?" Surprisingly, I said No. The one week iteration ensures there are no "beware the man in a dark room" syndrome but it also allows for very little time for re-design and refactoring. Programmers that like to tinker and sit back and re-design over and over again really don't work well in this one week iteration process.

it's not "what am I working on this week" but "what am I going to release this week"

A release has a lot of moving parts...but it enforces a well-oiled machine since everyone has to release their code every week. We are using a schedule that says: - Monday morning release , - Backlog Meeting Monday - Feature Go/No-Go Wednesday - Final check-in Friday (with time to fix stuff over the weekend or before Monday) On the minus side, if you have people on your team who aren't delivering or moving as fast, you really feel it on the Friday. But that's a plus too - because it forces you to move slower to get everyone up to the same speed. On the plus side, it makes Mondays much more exciting.

New FoxShow extends Southwest Fox Early-bird Deadline

Check out the latest FoxShow teaser.

While waiting for the final version of an interview with Doug, Rick and Tamar regarding Southwest Fox 2012, the organizations threw in a little bonus.

I'll sweeten the pot. The first five that register and mention the FoxShow will get $50 sent to them via Paypal from the FoxShow as well.


FoxPro VFP

Make 99% Invisible Visible

I mentioned 99% invisible on my last FoxShow - it's a fascinating and amazing show, talking about design, typically in architecture. For those who build software, what IS interesting is how design impacts a variety of things. Subtle things, like how if you close your eyes, a lane change feels like a 90% degree turn or just a quick flick of the wrist. Or how four uber-creative guys decided to ensure certain words were ensconced in metal. Or even more fun, what really should happen when patent-violators go bad.

However, more to the point, 99% Invisible is on KickStarter, a web site to help businesses or groups fund things through the crowd. The show started looking for some money to help broaden its scope so it can do more shows. But they hit that target almost instantly. Now they are trying to do something  a little more fun ---- reach 5,000 "backers". They're almost there (4,600 at this writing) with 4 days to go.

You don't have to give a lot of money --- in fact, if you listen to the show and don't like it, then don't bother. But if you do like it, why not pledge $5 or anything? (if you give more than $30, there are some "gifts")

Why give? Well, if you like the show, the original goal was to try and make more episodes every year, by helping one of the interns be able to work regularly on the show. That goal was hit within 24 hours. Now with increased backers, there are other goals: more episodes, make video episodes, who knows.

One of the best things of the show is that it is re-listenable. From the web site, "They’re produced to stand up to multiple listens and reveal more each time they’re heard. The ultimate goal of 99% Invisible is to make radio that inspires mindfulness and wonder in all the things in the built world."

If that doesn't sound like something (or anything) that could improve your software design, maybe you're not listening (or looking) hard enough.

Talking Lianja with Barry and Hank

Last month, I had the opportunity to talk with Barry Mavin and Hank Fay about Lianja, Barry's new tool for building a single application for Desktop (Windows, Mac and Linux),  Web and Mobile.

It's based on QT but what Barry has done is pretty damn incredible - a full development platform where  you can code in Python, PHP, Javascript and yes, FoxPro. So you're not just cross-platform in terms of OS but you're also cross-language. You can even mix code so one part can be written in JavaScript while another can be written in VFP. And Yes, it is eXtensible.

The FoxShow Episode is now available.

Learning from Kent Beck

Here's a great post that I'm sure others have seen and posted. Three guys had the opportunity to do some prototyping with Kent Beck, the creator of TDD and thankfully, one of them, Jakub Holý, documented it. I haven't ready Kent's implementation patterns book

The entire post is very long and detailed but I wanted to post some key takeaways as they apply to pretty much any project.

Make your code readable.  "Code is primarily means of communication."

KISS. "Apply simplicity at all levels."

Flexibility "Programs should be flexible in the ways they change, they should make common changes easy or at least easier. "

Approaches to coding. When thinking about Agile, people start creating sprints of 2 weeks or less. When prototyping, an even quicker sprint came up - "what would be the demo we would like to show at the end of the day. And his next question was what test to write."

Write tests that test needed functionality, at a high or unit level. "Speculating about failure points can be just as wasteful as speculating about design."

Write Code in the Test, then Refactor. (I know, think about it. I actually started doing this when I was first learning TDD and thought - "is this really what I'm supposed to do?") " Instead of thinking about how it should be organized (what classes to create, where to put them, whether to use a factory class or a factory method), why not initially write the code directly in the test method? You can always factor out the code later."

Focus on one thing at the given time. " If you notice along the way something else that needs to be done – giving a method a better name, removing a dead code, fixing an unrelated bug – don’t do it, put it on a task list and do it later. "

Symmetry in Code. "Symmetry in code is where the same idea is expressed the same way everywhere it appears in the code."


The entire post is a great read.

FoxPro VFP

Awesome Tech Conference + Tablet = Great Reason to Register

Doug Hennig and Rick Schummer just posted about Southwest Fox's new registration incentive. Pre-register before July 1st, and you may win a Samsung Galaxy, iPad or Kindle Fire - something to suit your needs whether you be an Android, iOS or just an avid reader.

With pre-registration, you also get a pre/post con and a chance for $150 scholarship or Stonefield Query . Last year, there weren't a lot of pre-July 1 registrations so the chances of winning are HUGE!!!

As an aside, one of the sponsors of SW Fox is Lianja and I recently had an opportunity to talk with its founder and will be sharing that interview on the FoxShow later this week.