The past few weeks I’ve been thinking about how I’d like to continue to build in 2010.

Whether you are on the business side of technology, or the implementation side, there are some common elements to all projects no matter the viewpoint.

Great software systems:

• Make users great. Make your users awesome at what they do when they use your software.  If you don’t, you have a dud.
• Are mature. People manage the system, the system manages the details.    Immature: People make their own systems, manage their own details, nothing is connected, or consistent.
• Understand the data is the system: The data is the system to the end-user.  Not your software.  The software is merely packaging to the information they need.
• Understand the integrity of the data: What is the data. What does it mean.  What states does it exist in.  How does it interact with other data.  Why is this important?
• Keep the edge: Software is built around the competitive advantage of magnifying and fueling the existing best practices of “This is how we do it here”.  Don’t lose it by doing it your way.
• Are invisible: “Don’t make me think” when I use it.
• Self-Monitor: Bring things to my attention
• Master the Complex: It ’s easy to make things complex.  It is hard to make complexity into something simple.  Understand that complexity is not the issue most of the time.  It’s confusion.

Maybe this will become a growing list!  Add your own below!

I’ve been playing around with the ColdBox Framework for ColdFusion for a few months.

What lead me to ColdBox was a period of discovering and playing around with the discoveries I made with ColdFusion 9 and it’s killer Hibernate ORM integration.

I could no longer program, ever again until ColdFusion 9 came out.. it made for a slower fall on new projects.  I decided to dust off the old exploration cap and started looking at what was new and developing in the ColdFusion world.

For about as long as I can remember I’ve been using FuseBox and my own frameworks prior to it coming into existence. In my modified FuseBox framework I have a simple, efficient, scalable system that has easily handled anything I’ve thrown at it, and more.  It’s very capable and rightfully so.

FuseBox is ColdFusion’s first major Framework and went on to dominate and inspire a lot of change in the PHP world not only with FuseBox itself, but the other great frameworks that exist in that language and maybe beyond.  Sitting in the ColdFusion world it’s nice to see that the ColdFusion “power with ease” eloquence was able to help spread this kind of empowerment, as much as ColdFusion’s continued track record of doing the best of similar languages and frameworks. No offence intended to any of the other great CF frameworks out there — I just didn’t feel the itch to shop around because I felt I had the good stuff at home.

No language, in my experience, has focused on the developer and their experience as much as ColdFusion.  Happy developers make great software.  I like being happy doing what I do.

I came across ColdBox and remembered seeing an earlier version around 2006 that looked really promising. It looks like it’s been delivering on it’s promises.  In defense of my beloved FuseBox, I haven’t looked at the new version in a few years because the one I use has worked so well!

The first thing that struck me was the sheer volume of documentation available on ColdBox.

I couldn’t believe my eyes.  Someone, actually, seemed, to get the significance of, and anticipate the needs of web application development, and ColdBox was the result.  This was like Allaire/Macromedia/Adobe continuing to anticipate the needs of application developers with ColdFusion. ColdBox looks to this software architect to be the next shining star of ColdFusion, if it’s not already.  It improves both applications and developer’s lives.

We know that application development and application developers are kept happy in some common and unique ways.

At first, I didn’t believe what I was seeing.  Everything I’ve needed to touch or use, with respect to a web application and it’s framework, seemingly, conveniently put in one place.  Internationalization, no problem.  Need role based security?  No problem.  Want to add a doo-dad?  Decide if you want an interceptor or a plug-in.  Next question.

What is a software architect to do when something makes him blink?  Get a second opinion from the smartest developer he knows.

My friend is someone I’ve known for almost 15 years.  We shared a path in school but I went off the ColdFusion deep end while he continued learning everything under the sun… except ColdFusion.

So I asked for his unbiased opinion.  Which he’s known to give.  I asked him, find me every fault in this ColdBox and the language of ColdFusion compared to all the languages you’ve ever used.  As a developer completely fresh to this, tell me if something is better than this, and why, because I might want to switch.

Expecting him to correct ColdFusion, and ColdBox the same way he used to correct the professors, assignments, quizzes, exams, and TA’s in university, he came back convinced that ColdBox and ColdFusion is great for developing web applications.  Not to say something else wasn’t, but if he’d pick something ot build on his own he just might use it, especially with the open-source ColdFusion engines like Railo and Open BlueDragon.

So, I’m not crazy.  That’s good.

Here’s the thing with ColdBox for me.  It does MVC, really well, for the web, for web applications.  Yeah, I know Ruby’s got this, ASP.NET’s got that, and Django has something else that’s great.  I have used them all, either with new projects, or maintaining existing ones.

The thing  that happens with any project, over time, is that it either becomes one you want to work on more and more, or one you don’t want to work on due to increasing complexity to add or modify tasks.

We can argue it’s up to the developer to keep things simple, but inevitable the platform and framework play a huge role in what we do, or don’t have to do, or what we do/don’t deal with.

If we put all the languages, frameworks into one pile, there is one key test I use to see the value of any tool.

It is difficult to make the complex into something simple; and it is easy to make the simple into something complex.  Will this help me make the complex into something simple, without dealing with the language, or framework’s complexities?

ColdBox, with ColdFusion seems to understand that most of us have to build things that are solid, reliable and scalable.  99% of web applications that are remotely successful grow.  We need a way to manage that growth and keep the garden looking nice while it grows.

Web developers often have to solve more than simple problems.  We have to solve complex problems and make them simple.   There is little doubt ColdFusion is the best integration language for the web.  It simply does more out of the box than anything.

I have spent the last 2 days working in ColdBox and my impression is this.

I have been amazed at how much of an application I have built already in ColdBox.  Actual business logic.  Actual problem solving.  Actual “this will make someone’s life easier, more efficient and productive”.

What’s changed?  I didn’t build my own roles based security.  I didn’t have to integrate internationalization.  I didn’t have to extend a framework to do more (or less) than it did.  ColdBox appears to be a framework that can be customized easily, or left alone and just run.

To potentially have the best of both worlds (Rapid dev of FuseBox and the scalability of OO-programing), compared to what was out there before, is more than a little staggering to this software architect.  I don’t care to re-invent the wheel, I want to solve problems and help people that are forced to work with poor software.

Beyond learning the ins and outs of ColdBox, I am slowly realizing it’s feeling much like FuseBox did.. the next tool I will use for possibly a long time.  Just like ColdFusion made web development power with ease, ColdBox takes Web application development to a similar of power with ease.

ColdBox allows you to leverage ColdFusion’s rapid application development in such an improved way that I don’t think has happened in several years.  As much as Fusebox first came out for ColdFusion and then spread to PHP, etc., and pushed the bar so much, I think ColdBox will inspire as well.

What’s most impressive is that such a powerful framework has been kept, if I may, simple, relative to the complexity of everything it handles.  That’s something ColdFusion did first, and better than anyone too.

In the coming few days I will start a Quickstart to ColdBox series to catch my first impressions and experiences of piecing it all together, to help you see for yourself what ColdBox could do for you.

Check out the slide show here, my thoughts below.

No One Cares About Your Stupid Little Startup

I have often wondered how a relationship between specialist (Web, designer, programmer, etc.,) can sometimes turn into the customer believing they understand everything better than the specialist, and how to do it.

This is when phrases like:

“Couldn’t you just..”

“All you have to do..”

“It should be pretty simple..”

“Can’t we make it really simple on the screen?  Why would that be more work to do it all behind the scenes?”

become more, and more common.

Problem? I don’t know. If you ignored everything clients say in this case, and only look at what they were doing, the client is basically saying they know better than you.  One could argue there’s something missing in the requirements phase.  Even when clients are the ones  that hired you to help them meet that impossible deadline that they didn’t know was a ton more work than they ever imagined?

Still, I’m not sure if it’s entirely the client’s fault for being this way.  I think it might be a mix of both client and specialist.  Clients tend to oversimplify and over-trivialize anything to make it something they can feel confident about so they don’t get taken advantage of.

What is true is this.

It is hard to make the complex simple, and easy to make the simple into something more complex.

Would we second guess or suggest doctors do something differently, or that engineers build a bridge differently (and without a plan) because we feel it shouldn’t be complicated?  I don’t know.

This leads back to the oft-referred issue of what color to paint the bike shed.

Why? Well, the less you involve and empower your clients, the more they will feel your craft is a magical dark science.  Of course, I’m the first guy to say I want to build systems and tools for people, not BE the system and tool through which they maintain their systems.  So, I’m forever doomed to try and involve clients as much as they would like to be and educate them.  It is already a luxury to feel understood by anyone, and it’s nice when you clients are able to join you if they so wish.

With that being said, I have a responsibility to first learn, and then demonstrate that I understand the needs of my client and how to best solve them in the way that best serves the client.  Maintaining or enhancing the clients competitive advantage is critical. It’s not about making my life easier, it’s about making life easier for my clients, and their clients.  This rings very true even when working on a startup.

I get it.  I’m pretty good at what I do and can reasonably be thrown down a well and come out okay.  Do I make it look easy?  I don’t know.  I have 15 years of experience and 4 vacations to show for it.  I read 2-3 hours a day on technologies and problem solving approaches.  I keep the saw sharp and keep busy sawing.  All to keep my value high to myself and the projects I work on, and to ensure my clients receive the best possible outcome.

Still, I hear, “well, can’t you just do this”.  I have accepted that this on some levels will always be the case.  I think helping clients understand that what I can do in 1 hour is only possible after 15 years of experience doing what I do, and that 1 hour of their time, while likely very valuable in the needs requirement of it, likely would not compare, must like I would be lost in their business.

I think I am going to explore the idea of “highest and best use” and incorporating that in to my working philosophy on all projects.  When we focus on everyone’s highest and best use and simply keep our nose out (or in) no more or less than it’s needed, it’s where 1 + 1 = 11 in terms of gains in productivity.

I build a Web application when I don’t want to:

- be supporting a thousand environments each with their own quirks. Specifically, viruses, trojans, software interfering, and making it work the same everywhere.

- worry about applying upgrades and taking lots of calls

- dealing with clients who lose their data

I pick a thick client when the computation is intensive per transaction, that would be simultaneous, or there is significant data transfer per transaction.

I like fixing everyone’s problems with one upgrade. It might not be for everyone, but it’s where the quality of my life and those I work for goes up. Making a web app work on a few different browsers may be easier than a ton of different operating systems in different conditions.

With the advent of Flex/Air you can provide an entire application experience in the browser. The browser is becoming the universal interface, whether it’s installed locally or in the cloud.

Web apps have their cons too. I just am more motivated to build web apps as the pro’s seem to outweigh the cons for the projects I am choosing.

Crafting software is like.. building a house.

You can try building it without a blueprint or plans or an architect or qualified tradespeople and it will almost always cost you much more and you will have constant issues.

Second, just because you can build a shed without a blueprint, doesn’t mean you should build a house without a blueprint.

Would you buy a house, or want to work on a house that was built without a blueprint?

Ok, Ok.  But startups are different.  You can’t get caught up in analysis paralysis.  True.  You shouldn’t also go without a rough map.  Don’t stand still, and don’t run like a madman in 10 directions at the same time.

Pick a path, a philosophy and why you’ll be making certain decisions.  And let it guide you.  You’ll know when you’re overdoing a room in the house or spending too much time on a closet when you still need to build a bathroom or a kitchen.

One thing I’ve found myself doing more and more in ColdFusion is using it for it’s integration powers to parse data, or do batch performing tasks.  With it’s Java underbelly, ColdFusion does most things great, and if you want even more performance, tie into the Java layer!

I come from the group of people who pursue the dream that computers and technology should make people’s lives easier.  That’s why ruthless automation is at the center of most startups, or businesses that are growing.  Keep people dealing with people — what they do best, and let your system handle the details for you!

1) Maintain a file upload table (Parent table). For every file you upload you should be able to keep a list of each file and what status it is in (uploaded, processed, unprocessed)

2) Temp table to store all the rows of the data file. (child table) Import the entire data file into a temporary table. Attempting to do it all in memory will inevitably lead to some errors. Each row in this table will link to a file upload table entry above.

3) Maintain a processing status – For each row of the datafile you bring in, set a “process/unprocessed” tag. This way if it breaks, you can start from where you left off. As you run through each line, set it to be “processed”.

4) Transaction – use cftransaction if possible to commit all of it at once, or at least one line at a time (with your 5 queries). That way if something goes boom, you don’t have one row of data that is half computed/processed/updated/tested.

5) Once you’re done processing, set the file name entry in the table in step 1 to be “processed”

By using the approach above, if something fails, you can set it to start where it left off, or at least have a clearer path of where to start investigating, or worst case clean up in your data. You will have a clear way of displaying to the user the status of the current upload processing, where it’s at, and where it left off if there was an error.

If you have any questions, let me know.

Other thoughts:

1. You can increase timeouts, give the VM more memory, put it in 64 bit but all of those will only increase the capacity of your system so much. It’s a good idea to do these per call and do it in conjunction with the above.
2. Java has some neat file processing libraries that are available as CFCS. if you run into a lot of issues with speed, you can use one of those to read it into a variable and then into the database
3. If you are playing with XML, do not use coldfusion’s xml parsing. It works well for smaller files and has fits when things get bigger. There are several cfc’s written out there (check riaforge, etc) that wrap some excellent java libraries for parsing xml data. You can then create a cfquery manually if need be with this data.

I recently read that a product is 80% marketing and 20% actual product.  That probably would explain why garbage can succeed and great software can fail.

The truth is as developers, startup entrepreneurs, it’s critical to know how to sell and market.  Without learning the ability to have the conversation to sell, there may not be much of a reason to start building anything.

Often, as is the case, we put off the unfamiliar and get working on the familiar, “to make some good progress”.

This often means programming.  Start building.  Get out the measuring tape.  That carpenter’s pencil, the wood glue.  Get to it.

Here’s the thing:

Just because I can build a shed without a blueprint, doesn’t mean I should build a house without a blueprint.  Especially if I don’t know how to sell the house, or build a sellable house.

Building without the plan is in essence hurting your hard work even more, and delaying your potential success.  The sooner you start your conversation, start your story, and get potential customers engaged and involved in a beta, the greater you have increased your risk.

Instead, learn to start the conversation first. Learn to spread the news first.  Learn to attract the traffic and input you need, first.

We know you can build anything, at the speed of light.  But those 6-12 months will still mean you did no marketing at that time.  There’s little more helpful than having a mailing list already built up of potential customers as well as some google ranking love for your product already.

If you’re still not sold on it, try this law:

Less code = fewer bugs = quicker release = quicker iteration = quicker profitability

—