Every business needs cashflow (and profit) to survive like the body needs oxygen, food, and air.  Just because a business has cashflow, doesn’t mean it’s a success, much like we aren’t a success in life just because we sat around and survived.

If you have to mislead to make a dollar, it’s like tricking a girl into liking you.  You might make some money/trick her for a while, but it won’t last.

The better the mutual fit, the better the relationship.  As is often the case it’s best to see if you can work well together.  The client, or the vendor, alone, can’t make the relationship work.  Both have to be present.

As for finding the right work..

Know your product.  Know the value you deliver.  Know the clients it will benefit.  Only sell to them and you’ll have a lasting business.

Always generate more value than which you are paid. Otherwise your client turnover rate after they feel “had” will be much higher than it needs to be.

It’s easy to try and be someone else in business.  The problem is it always comes back full circle.  If you like honesty, and integrity, and when people eat their own cooking before giving it to you as advice, do it yourself.

Not every customer values it, but not every customer is for you.  There’s a big difference between a good dollar and a bad dollar.  It’s tough in the start but it’s worth it.

Be a defender of keeping goodness and kindness fashionable.    Your startup is your declaration of your moral and professional independence.

For one of the original software development bloggers, at the center of the startup, micro-isv movement to make a decision like this, it seems a little strange at first..

Joel mentions a number of reasons that I think are interesting of what a startup may face, once a startup has.. started up.

1. Part of the reason he’s no longer writing is that he has so many customers that his blog posts seem to deeply offend one of his clients in one way or another.Plausible? Sure. But isn’t differentiation what a product is built on?  I think this could be the topic of a blog post on it’s own by Joel to see what kind of things others in startups have to look forward to when you get large(r).
2. Growth means there’s revenue for traditional advertising. I would think, though, that tools for developers are ultimately best directly connected to them instead of magazine ads?

Joel might be big enough and he doesn’t need to, or can’t benefit from blogging as he did prior…  With Stack Overflow taking on the answer / thought market and opening things up beyond him, maybe there’s room for a lot more voices, that can be found easily.

Maybe Joel was developing the best bug tracking software in the world, and attracting the best developers in the world, so that when FogBugz reached it’s sweet spot, he can go onto building the best software company in the world?

Who knows.

I do know that writing, and sharing doesn’t leave you once you start, and know the value of being shared with, especially after many years.

Joel’s posts have helped so many that I don’t think many will lose their value or relevance.  Whether it was the pay-scale matrix, or why the command and conquer or econ 101 management won’t work with software developers, it’s rare to have reasonably concise, applicable, exploratory rants that were sane as it’s readers most of the time, and willing to have it’s share of mind-stretching ideas like anyone being stretched by growth.

If this is the last of Joel blogging, thanks for doing it.  The fact that Joel replies to emails and shared what he learnt so others could join the movement to make the world a better place with better software.

Will it be the last we hear from him in books, conferences, articles elsewhere..?  Doubt it.  His recent introduction to mercurial at www.hginit.com is a prime example.

I hope Joel continues to create and write, and if not, we see his writing has inspired others to write and share.

Joel I know you read more than you ever let on, so if your eyes reach here, which I’ll do my best to ensure, remember that with our talents we have a responsibility to share what has been shared and taught to us by life and others.  No guilt trip intended, the world owes us nothing.

Let’s step back from this and see the general picture.

Does this decision by Joel mean blogging is ultimately useless for startups? I don’t think so. At all.

Most companies, indeed, do use their blogs for boring news releases is relevant.

Blogs are all about relevancy. Blogs, like products that provide relevancy thrive.

Blogs will always have their place to share information, and for us, resources for startups looking to reach their market through the public seeking their content.  If you don’t have the marketing money, a blog is a key way to demonstrate and share expertise and knowledge.

I can say that the last year of writing this blog has showed me that I need to write more, and often.

This event is a groundbreaking start for the software startup community in Edmonton.. I’ve had a chance to meet the organizers and it’s definitely folks who eat their own cooking and are pursuing startups of their own.

Working in startups can be isolating at the best of times… This is a fantastic opportunity to meet your peers and see where things are headed with events, and your input.

See you there!

Find out more at StartupEdmonton

In building secure applications that let me sleep at night, I have learnt a few things:

1. Security is relative. You must keep up, and ahead of the curve.  Your thinking and design must be steps ahead of what’s happening and what may be possible in the near future.  In the end, if someone wants to, given enough of their time, resources and money (more than what you have spent) it, still, conceivably, is possible that security may be compromised.
2. Security vs. Convenience. Unless you are a expert of making complex security disappear “under the covers”, there is still a fundamental  acknowledgment that has to be made.  The more security you implement in an application, the performance, and usability of that application becomes less than simple.
3. The path of least resistance. Instead of building a big, thick wall of security, consider building many, thinner walls. Just like someone who asks you a question instead of googling it, someone wanting access to a system will want to do so the quickest way possible.  If they are out to find the next outpost, they will move on if there is layer after layer of security, like an onion skin.

   Why?  Most unscrupulous attempts to access a system aren’t really about you.  Most valuable is the most generic.  Your server resources to be illegitimately used to send out spam, etc, and not necessarily for what your application itself does.  The reality is most attempts to break into your site will be automated scripts/botnets that sweep the entire internet.  While you can build mega security features, a lot can be said by good design and putting up multiple “walls” instead of one big “wall”.  Design your application to inherently check and enforce security as much as it can internally.  Package it with smart public facing interfaces, properly hardened and tested with client and server side scrubbing and validation, and we have a start.

4. Passwords be safe. Do your best, reasonably to secure the single, most vulnerable part of your system.  Relative to the sensitivity of what is behind the password, implement password security measures.  Logarithmic delays between failed attempts.  Log and report invalid attempts. Encrypt your passwords.

   One of the biggest things you can do if/where necessary is to store your passwords securely.  This is a great article on How to safely store a password.

If you have any ideas to add to this list, please leave them in the comments.. I’ll update the list!

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!

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.

The main thing I’ve found about Social Media that is unique is instead of customers seeking products, services and solutions; the products and services find the clients by reaching them.

People may look in places.  Facebook, Google, Twitter, etc.  What reaches them through these means though, is something entirely different than a traditional marketing sense.  People are no longer looking for a product.  We review.  We read.  We compare.  We debate.  We review some more.

In all of this reviewing and deciding there is a taking of people’s opinions.  I recently read something that consumers will trust a review 80% of the time in their purchases, and advertising (online or otherwise) about 15% of the time or so.  I wish I had the link and if I find it I’ll post it.

This month he spoke at the 2009 Startup School as part of an all-star group of speakers.  He posted a summary of his talk on his website titled “What Startups are really like“.

I found this essay struck a few deep chords with me.  Having been self employed for almost 10 years full time now, and 15 years since I started freelancing… this essay had me nodding a lot since I always had a startup aspect to at least one project going at all times.

I highly recommend it for anyone to read in general as there is some good advice that everyone can benefit from.

Paul spoke about 19 key points and I wanted to offer my thoughts on a few of them, one post at a time, from my own experiences in the last 10 years.

1. Be Careful with Cofounders

This was the surprise mentioned by the most founders. There were two types of responses: that you have to be careful who you pick as a cofounder, and that you have to work hard to maintain your relationship.

What people wished they’d paid more attention to when choosing cofounders was character and commitment, not ability. This was particularly true with startups that failed. The lesson: don’t pick cofounders who will flake.

Paul is bang on.  Do not confuse activity with results.  Do not confuse what a potential cofounder says, does, and says they do.

Define success.  Define how you’ll get there.  Define why it’s being done that way.  This is one place where the “why” of what you’re doing is infinitely more important thatn “what” you’re going to build, or “how” you’re going to build it.

I have had more experiences, successful and not; working with strangers, and friends on many projects to have learnt this the hard way.  Success is doing what others are not willing to do, longer, harder, deeper and when some may walk away. I have heard that you shouldn’t work with friends and done it anyways.

I have worked with complete strangers and ended up with the same results.

As cofounder friends, you must:

• have a history and understanding of each other as friends first,
• to frame the relationship as ‘co-founders’ in one place and as friends in another.
• know if you’re good enough friends to get through adversity together.   Separate the buddies from the brothers that have your back anytime, anywhere.  Those are the people you need with you in the trenches.

Working with a cofounder that is a friend is not much different than dating and deciding to be “serious” friends.

Beyond that, as good friends:

• Have you been able to solve other problems together using each others strengths?
• How do you resolve or go through things you don’t agree on being important, or solving one particular way?
• Have you had a disagreement that was major enough that we both were able to still come together, talk, understand each other, and choose what’s best apart from your mutual preferences?
• Are you in a startup for the same reasons?
• Is your co founder looking for the long haul and you’re looking to cash out?
• Life wise, would you handle marriage (if single) and the impact of other commitments in a similar way?

Guess what you’ll be doing in a startup!

The key requirement of a cofounder is a persistence and dedication to do what is needed to be successful. That’s it. Finding out what’s most important to do, why, doing it when you need to and then getting to it is what seperates the brilliant software engineers with the next google under their hat that will never release, and the guys who focus on shipping.

You have to find what to do, how to do it well, and always remember why you are doing it that way.

If you don’t share the “why” with a cofounder and you cut corners where they want process, etc., you will be spending time dealing with each other than dealing with solving a problem.

When you have that, getting on the same page is one thing, but staying on the same page becomes something you can regularly review.  Sharing a passion and wanting to pursue it with equal dedication is critical to any startup.  If one founder is coasting or decides other priorities are taking precedent, it’s critical to look at what a person says, what they do, and what they say they do.

I’ll publish this for now and if I come up with more I’ll mark the title of this post as updated.

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.