Archive for the ‘Software Development’ category

Michael’s Laws of Software Development

February 11, 2011

In the course of my career, I’ve come up with a few rules/laws that I’ve found to be true time and time again. Sadly, these laws are based on actual experience. So I thought I’d share them with the Software Development community (or the five people who read this blog):

I. Michael’s Immutable Law of Software Requirements

Users always perform the same process to the same data every time…except when they don’t.

II. Michael’s Law of Vocabulary Variance

Words like “required” seem to have a different meaning to a developer (“always must exist”) than to a user (“it must exist, unless I don’t feel like it”). Also “optional” also seems to mean “required”; unless, of course, if it doesn’t.

III. Michael’s Law of Feature Longevity

The feature that is a “must have” and is the hardest to code will be the feature that will be reversed in six months. See Laws I and II.

IV. Michael’s Law of Prioritization

Every feature or request is absolutely the highest priority, even if the requests are from the same person and there’s only one programmer to implement them.  When pressed to prioritize which features/requests should be addressed first, the answer is “all of them”.   Apparently, having dual core processors on computers now means that a programmer can program multiple features simultaneously.

V. Michael’s Law of Project Accountability

The lateness in delivery of code for testing is directly proportional to the perceived failure of the project.  However, the length of time it languishes waiting for testing and signoff, even if greater than the lateness of code delivery, has no effect on the perceived failure of the project. In a word, it’s always the developer’s fault.

VI. Michael’s Law of Diminishing Returns

When joining a successful company or new group within a company, that company or group will immediately lose resources (budget, personnel, etc.) approximately one year after you join it.  And it only gets better from there!

I’ll continue to update these as I uncover more laws of software development.  This blog would not be possible without the pioneering work of Mr. Murphy and all who came after him.

In Praise of Maintenance Programmers…

July 2, 2010

I know this is supposed to be a blog about development, but I want to spend a few moments in praise of a group of technologists often overlooked in the discussions of software development: maintenance programmers.  There has been much discussion about “rock star” developers, particularly from Joel Spolsky at Joel on Software.  And that’s great.  Any discussion that raises the social standing of programmers is a good thing!  But I want to talk about the unsung heroes of software development and IT – the maintenance programmers.

First, a confession.  This topic is slightly self serving, in that in my new day job, I am now a programmer in the maintenance group.  In fact, my recent trials and tribulations at work made me really appreciate how hard maintenance programming really is and how the skills essential to maintenance programmers are a little different than a developer.

The Obligatory Star Trek Reference

Using Star Trek as an example, I see developers as the Starfleet Engineers who build the starship and the maintenance programmers as the Scotty’s of the world.  Think about it – Scotty is always enlisted to perform miracles to make the ship work because Kirk (the user) wants it to do something it was never designed to do or has messed it up so badly that it needs heavy duty maintenance.  And Scotty usually has to perform these feats of miraculous engineering under extreme time constraints or without key personnel or resources.  Sounds like the kind of day I had every day for the last week and a half!

Obviously, Star Trek is fictional because Scotty always gets the accolades and praise…when was the last time maintenance programmers got praised for working diligently to fix a problem?  Usually it’s, “That’s nice, now here is my list of another 20 things for you to fix…”

Skills Essential for a Maintenance Programmer

  • Ability to Read and Decipher Someone Else’s Code – It goes without saying, that most of the time, maintenance programmers don’t actually write the code they have to support.  Nothing says you’re going to have a day of fun like digging into a steaming pile of…code.
  • Ability to Be a Forensic Scientist – Not only do you have to be able to read the code, you have to figure out how it actually works in the REAL WORLD.  Developers rarely see their code live in the world and don’t have to worry about pesky details like when the database table is locked because one process is doing something while another is trying to update the same table.  You have to make friends with every kind of debugger/trace tool that you can lay your hands on so that you can do a little CSI work on the culprit (the problem).
  • Ability to be Sherlock Holmes –  Hand in hand with the CSI work, you need to be able to logically deduce what is happening from the (hopefully) piles of evidence you have discovered.  Remembering that when you you have eliminated the impossible, whatever remains, however improbable, must be the solution,  goes a long way in maintenance programming.
  • Dogged Persistence – You have to keep beating your head against the problem until either you win or the problem miraculously disappears.  This is where the rubber meets the road…you’re the one who has to get it working for the users.
  • Being a Jack of All Trades -While it’s great to be an expert in a development language, once that code hits the real world, it is likely interacting with any number of other things out of your control (like it might have been in development) – like web services, networks, databases…you name it.  Knowing at least something about all of the elements of helps give you an appreciation for all of the possible areas to explore.
  • Intuition – Sometimes intuition is the best tool for trying to figure out what is happening.  This is sort of an addendum to the previous skill.  When you’re grounded in a varied background, you begin to make connections and improve your  intuitive skills.
  • Patience – You really need to have the patience of a saint to keep from going crazy.  Each roadblock that’s thrown up by the code or the production environment has to be either worked around or driven over.

The Stigma of Maintenance Programming

But let’s face it, maintenance programmers don’t get treated the same as developers.  Why?

  • They are not perceived as being able to grasp new technology – Maintenance programmers may seem like they don’t “get” new technology, but I don’t think that’s universally the case.  In my limited stint as a maintenance programmer, I have to understand a wide variety of things – XML, web services, C#, Java, JavaScript, SQL Server, and mainframe JCL to support the applications.  Sure there’s old technology, but there’s a good chunk of new technology that I have to learn quickly.  And usually without the training that the developers got so they could figure out how to develop the system.
  • Keeping things going is not as glamorous as building new stuff – This is universal it seems.  This happened at a previous employer. I’ve had co-workers and friends that never seemed to do well and weren’t looked on favorably by management because they went about the job of keeping things going silently and efficiently.  I know that some of peoples were on the list of people to be downsized because they weren’t producing new exciting work.  But they kept the business going.  If it were my business, I would have hired them without reservation because they were model workers.  Yet somehow, the idea of doing what’s needed to keep the business going is not as important as producing new things.  I don’t care how many new systems/products you develop, if you can’t execute on a day to day basis, it just doesn’t matter.
  • They are not “real” programmers because they don’t create anything – That’s simply hogwash.  Maintenance programmers are usually the ones who have to extend/recreate/totally rewrite the original application when the business needs (or the user’s minds) change.  They are the ones usually stuck with refactoring – now that’s a REAL programming task.

What Can Be Done to Fix the Maintenance Programmer’s Lot?

In reality, probably nothing.  As a business culture, we only seem to care about the next new thing.  I realize that business can’t just stay focused on doing the same thing all the time, but if you don’t have stable, dependable systems, all the new development work in the world is not going to keep the business going.  So, here’s my wish list for what could be done to help maintenance programmers:

  • Recognition for the important work that’s done – Sure, there might be some sort of celebration for a new project that was completed, but how about some sort of recognition for someone who finally fixed a long standing problem?  Came in in the middle of the night to get the jobs running?  Yes, I know it’s part of the job, but you know what?  So is delivering a project if you’re on the development team.  A little recognition would could go a long way.  It doesn’t have to be an elaborate thing: an email to the group praising someone’s efforts or a mention at a staff meeting. Although food is always good!
  • Rotate developers and maintenance programmers through projects – I think it would be great if one maintenance programmer could join a specific development project, while one development programmer took a tour of duty as a maintenance programmer.  I think it would have very many positives – maintenance folk get in on the ground floor and get to build something , they get to see the struggles that developers have in trying to create something from nothing, and they may get a chance to pick up a new technology.  Developers get to see what it’s like to have to support code over the long haul and deal with the inevitable changes that occur as the software is let out in the wild.  This may help inform their development choices later…especially if they know they may have to support it at some time.
  • Make sure that maintenance folk get the same training opportunities as developers – How many times have you seen this?  A new technology comes in and the people who are going to implement it get training.  Down the road, they move on or the system moves to the maintenance group…who now have to figure out how to support or even change this thing.  But there’s no training for the maintenance group because the company has already spent enough money training people…who are now completely consumed doing something else and have no time to help.  If it’s important in enough to train people to develop with a technology, it’s just as important to train the maintenance people!

So to all my fellow maintenance programmers out there:  keep the faith and keep doing what you’re doing to keep things running!

Running…and Software Development

August 17, 2009

This spring, I took up running.  To anyone who knows me, this comes as a huge surprise.   Up to this point in my life, I have always hated running.  I decided I wanted to get healthier and start losing weight, so I started using the Wii Fit we got at Christmas. I gradually worked my way up to being brave enough to do the running in place exercise.  And I sort of didn’t hate it.  I actually got good at it and was soon running a couple of virtual miles a day.

I thought, “Hey, I can start running outside”.  So I laced up the sneakers and ran to the end of my street ( about 0.6 miles)… and felt like I was going to die.  For the next three days, I felt like my thighs were going to explode everytime I moved.

A couple of weeks later, I tried again.  This time, I got a real running plan and followed it.  It started slowly with more walking than running.  Each week, and later each run, increased the amount of running and decreased the amount of walking.  After eight weeks, there I was running for 30 minutes straight for the first time in my life.

So What Does This Have to Do With Software Development?
I’m in the middle of rewriting an application and trying to upgrade my skills all at the same time.  And my result to date has been much like my first attempt at running.  I think I can do it because I’ve done it before and I start hammering away…and then it doesn’t work and my head starts hurting from not seeing what I should be doing.  I’m trying to run before I’ve built up the mental muscles that support the understanding that I need to move forward.   What I need to do is to start walking and adding my running minutes gradually. 

Who Cares?  Why Is This Important?
I think one of the weaknesses of technical people (myself included) is that we don’t like to admit we don’t know something.  We’re often thrown into circumstances where we have to do something we’ve never done before.  And so we boldy go where we’ve never gone before….and get frustrated.  We may reach  the solution, but we feel like there has got to be a better way.   Sometimes we get lucky in the Google roulette and find a code snippet that will do most of what we need without ever having to think about it.  Sometimes, this is a good thing – especially if it’s for one esoteric feature that a user ABSOLUTELY has to have, but it’s not  part of the core of the application (like say, a routine for changing the colors of the graph reports).  But it’s very easy (and tempting for the sake of expediency) to throw together a whole application of disparate snips of code…and that is a recipe for disaster.

What we should be encouraged to do at our places of work or even on our own, is to embrace the beginner’s mind.  By beginner’s mind, I mean that stage where you go through the basic exercises and start to make the connections that enable you to figure out how to more and bigger things.  In beginner’s mind, you don’t necessary even know what you don’t know.  But you start slow and build the intellectual muscles that you need to start.  And you continue to build those muscles so that you can do more.

How Do You Begin the Journey of a Thousand Miles?
 With a single step, Grasshopper.  By that I mean start at the very beginning.  For me, I’m going back to the .Net books that I have that patiently walk you through the steps to building a .Net application.  No more skimming to find the section that I think will do what I need to do. I also will look at Microsoft’s tutorials online and also squeeze in some online training.  As I learn, I will start to apply each piece to my application, re-enforcing my learning.  To speed up, I have to slow down; move carefully through the preliminaries until I have mastered them.

Because running is just like software development – just because you have been doing for a while, it’s still never really easy – it just gets less painful.

My Ideal Job

August 7, 2009

This started out as a completely different post – one about spending the last month (plus) in Unemployment Nation, but it occurred to me that I should be focused on what I want to do.  I decided that I’ve done enough wasting enough mental energy on my previous job and the way I was discarded…I mean let go. 

Since I’m now looking, I’ve been think about my ideal job.  I’m imaging a place called Utopia Software Company.  Here are some of the elements of Utopia Software Company:

IT/Development  Work is Either THE Product of the Company or an Integral Part of the Company’s Products – In my previous IT jobs, IT was always viewed as, either a necessary evil or a black hole where money was poured with nothing coming out.  When the inevitable tough times would come, IT would be the first on the block.  In my first job, I watched IT get chopped in third. Recently, my IT department of three employees was reduced to one contractor.  The companies I worked for had lots of intelligent people working for them.  Companies where technology (not necessary computer/electronic) are key. You would think that if they could give IT at least some of the resources it needed that there would be a big return for the business.  But what IT got was usually the shaft.

Also, IT had little or no clout within the organization.  Trying to get things done that were needed for the IT organization to work better was damn near impossible.  No one wants to hear that we need a new air conditioning unit for the computer/server room or that we need this or that tool to do our job more efficiently.  And when trying to get the attention of management, if it had to do with IT, forget about it.  As friend of mine said, “You can’t spell shIT without IT!”.

That’s why I want to be part of an organization that either makes software or view software development and the systems as a key part of their business.  IT would not be considered a second rate department, but critical to the success of the company.  I would like to feel valued and supported.

An organization that ACTIVELY supports learning – One of my biggest frustrations with my corporate IT career has been the lack of opportunity for learning, particularly for classes.  I’ve been part of two corporations who SAY they value learning, but I have not seen it pan out.  I have rarely been able to take training I need just to be able to do my job, let alone learn any new skills.  It’s a good thing I can pick things up quickly, because that has been the way I’ve had to learn almost everything.  I did have one good manager who really let me take a number of courses to improve my skills – that was nearly 13 years ago.  I’ve had almost zip since. 

I want to be part of an organization that really encourages learning and gives people the time and resources needed to learn and continue to learn.  Allowing people to take web classes while trying to continue to do support work doesn’t cut it.  If I’m supposed to be learning something, I want to be learning it and concentrating on that. Not trying to learn a new database technology while supporting applications, correcting data entry errors, and fixing printers.

Pay and Compensation

I’ve worked for two companies whose view of pay and compensation couldn’t have been more different.  One paid people in proportion to their performance – the percentage of your raise was clearly tied to your performance that year.  The other company SAID they believed in performance based compensation. But if you worked your ass off or just did what was needed, you might get the same 3.5 %.  The one company expected alot out of you, but actually gave you something back.  Most managers at that company would give you time off if you had to do night or weekend support.  The other company wanted you to work even more than the former, but you were lucky to receive a pittance of an increase and no time off if you had to give up nights, weekends, or even holidays for support.

I want to work for a company that rewards their employees for a job well done with meaningful increases.  If the company expects a great deal of their employees, the employees should expect a great deal in return.  And night, weekend, and holiday support work should be compensated by either time or money. 

Room to Grow

In both my corporate jobs, there really was no place else for me to go.  In my first job, the only way up was into management and at the time, I wasn’t willing to make the sacrifices (move away from my family) to make that happen…I’m still not ready to make that sacrifice.  In my last job, there was, at least on paper, more technical levels for me to pursue, but I knew that no one would want to have someone of that level working in the plant…apparently they didn’t even want to have someone of my level working at the plant…but I digress…

I want a job where there is a technical and management ladder.  I was a pseudo manager for a while (all of the responsibility, none of the power), and I’m not sure I was real great at it then.  I’ve learned a lot since then (particularly what NOT to do) and think I have a better mindset for being a manager, but I still like technical things.  I’m not sure I’m ready to go into management, so I’d like a position where I could advance either technically or managerially.

In Search of Utopia Software Company…

Am I asking too much?  Does this company even exist?  In Central New York (state)?  That’s the kind of company that I would like to build some day, but for now, I’d like to just see on functioning in the wild.  My horror stories of Corporate IT are mild compared to many I have heard with psychotic management and cutthroat politics – I’ve been spared that.  But wouldn’t it be nice to work for Utopia Software Company or at least in the IT department for Utopia where dreams can come true?

Death of the Single Developer?

June 16, 2009

I was reading the following article in InformationWeek and I was struck by the following quote:

 “The cliché of the solitary coder is dead.”

The article goes on to talk about a number of Corporate IT application development groups that have done some pretty phenomenal things for their companies. 

This is a subject near and dear to my heart as I am the IT department at my day job and I am the only developer for my business.  I can categorically say that in my day job, it is certainly not by my choice. 

Is It Possible to Deliver Great Results By Yourself?

I don’t know – I think it depends on the developer.  I can say that in my twenty plus years of IT, the amount of stufff you need to know has grown tremendously.  For the applications that I typically develop (your based Create Report Update Delete – CRUD applications – and yes some of them are just that), here’s a short list of what you need to know:

  1. Database/Table Design
  2. Object Oriented Design
  3. User Interface Design
  4. Requirements Gathering
  5. Application Development tool
  6. Testing
  7. Implementation/Installation Packaging

Notice I didn’t even get into the application development tool of choice or platform – Web vs. Windows.  This is a pretty steep learning curve for anyone.  A person can become a master in any single topic I listed and still not know everything.  I find it ironic that while a development tool like Visual Studio .NET can make you more productive because many of the things you might want to do are part of the .NET framework, it is so huge that it seems like an endless task to figure out how to do what you want.

Is It Desirable?

I don’t know;  I have mixed feelings about that.  As a developer, I love owning the application and being able to point at it and say “I built that.”  That’s on the good days when everything is running as it should.  On the days that there seem to be more new bugs than lines of code in the system, you want to hide in a cave, lest the users arrive with pitchforks and torches…

But the practical reasons that it is not a good idea are:

  • All the knowledge of the application is embedded in one person’s head.  I don’t care how well it’s documented, there’s stuff that someone will want to know quickly that is very difficult to extract from a source code listing.
  • There is no second eye for design choices.  It is that person’s design, warts and all.  While I don’t recommend design by committee, having other resources to assist in the design phase will certainly create a better product.
  • The pressure to get it done can override a developer’s natural (or unnatural) tendencies to follow good development practices.  Sara Chipp wrote an excellent description of this phenomena here

Is It Really The Death of the Single Developer?

In a word, no.  For one very simple reason: COST.  Many small and medium size companies (even if they are part of a bigger corporate parent) can’t justify having a team of programmers.  These companies always need someone to develop something that works exactly the way the business works.  As much as the big software vendors like to throw everyone in the same functionality pool for their applications, truth be told, each business is unique.  It has a unique structure, culture, and institutional history.  All that stuff becomes the DNA of their business processes.  And as a developer it’s your responsibility to turn that DNA into something – hopefully not a genetic mutant hell-bent on world domination…

Can a single developer do that?  The answer is…it depends.  If the company realizes all of the things that a developer can bring to the table and is willing to invest in that developer in terms of training and decent tools to do his/her work, it might just work.  The developer does have to be linked into the business and know what’s happening.  He/she has to be sensitive to the business climate, really understand what it is the business wants from the developer, and have his/her pulse on the work going on out on the floor.  Likewise, the business needs to listen to the developer when it comes to what’s needed to accomplish a project in terms of time, money, resources (not necessarily other developers – users too!), and respect the developer’s technical decisions and expertise.  If the developer says “If we don’t start to rewrite this critical business from Visual Basic 6 to a .Net platform now so that it will run when we migrate to Vista/Windows 7, we are going to be dead in the water”, you might want to listen to him/her, instead of (figuratively) patting him/her on the head and saying “That’s nice. When’s the next release?”.  If you find a company like that, please let me know…

However, in many small shops, the developer is also the Server Admin, Network Admin, PC Hardware and Software Support, and Printer Repair person.  Now take that list from above and then add everything you need to know to support THIS list of duties and I fear that the majority of people’s heads would explode at the amount of knowledge needed.  And end result?  I think it’s safe to say that the company gets exactly what they paid for – a jack of all trades, master of none.

Conclusion

 I still think it’s possible for a single developer to succeed.  While the single developer has many hurdles to clear that aren’t found in a development team, there are two things that the single developer and the development team both need to succeed – a clear commitment from the business to support the development team and excellent communication between the team/single developer and the business.  If I ever can find a company like that, I’ll let you know!

Crisis of Confidence and Motivation

March 25, 2009

“You fall for reality,
You’re bruised and defeated,
Then you learn to fall in love with yourself.
That’s motivation”

“That’s Motivation” – David Bowie, from the movie “Absolute Beginners”

It’s been one of those weeks where I feel I’m tottering between brilliance and stupidity.  This is one of the hardest parts of being a solitary developer.  One minute I’m feeling great because I’ve done something I didn’t think I could do, the next, I can’t figure out something that I should easily figure out.

Although I’ve been developing for 13 years now, I’m old enough that I missed out on object oriented development in college and I’m now trying to play catch up.  In my own development project, I’m working on a basic Windows application talking to a database.  It should be straight forward, but I seem to be complicating it for myself.  And I find myself constantly rethinking what I’m doing  – should I use the basic DataConnectors or should I look at making it object oriented?  Should I be doing Object Relational Modeling?  Should I use Access, SQL Server Compact, or Sqlite for the back end database?  All the while I feel like I’m spinning my wheels and redoing work I’ve already done.  Or spend a lot of time on something and scrap it and take a different approach.

This is one of those times when I desperately wish I had an other developer as a reality check and guidance.  So when faced what seems like an endless task, how do I get enough gumption to get going on my development work?

Here’s how I do it:

1) Blog about my troubles– If I get my troubles and feelings down in actual words, they stop rattling around in my head and distracting me like shiny little toys.  Also, feedback from the blog might also point me.

2) Step back and break what I need to do down into tiny tasks – My biggest problem with this step is having enough continual time to look at what I need to just build a to-do list that I can whittle down to nothing.

3) Let it simmer and come up with “brilliant ideas” in the shower and the drive to work – I sometimes comes up with my best ideas here.

4) Just keep swimming – Dori’s mantra from Finding Nemo is a good plan.  You got to keep moving because stopping can be death, especially in development.  Keep moving.  Keep trying something, anything.  Eventually you will figure out what works for you.

So I’m going to make some definitive choices (at least for now) and break this project down into bite sized chunks.  I think I’m overcomplicating things and I really should just evolve back to the KISS (Keep It Simple Stupid) method.

Wish me luck!

“I’ve nothing much to offer,
there’s nothing much to take,
I’m an absolute beginner,
but I’m absolutely sane.”

“Absolute Beginners” – David Bowie, from the movie “Absolute Beginners”

Army of One

March 9, 2009

If this is your first time here, I should say that I am the lone software developer in both my day job as well as in my company.  This is both a blessing and a curse.  It’s like what Uncle Ben said in Spiderman “With great power comes great responsibility”.

What’s Great About Being a Single Developer
Freedom
-You pretty much have the ability to do whatever you want.  If you don’t want to follow a methodology, you don’t have to!  You can build the system any way you want.

Ownership – You own the application.  You know its ins and outs, all the dark places with the twisted code that you took you forever to get right.  It has your stamp on it.  It’s your baby.

Pride – When it’s working and doing exactly what it’s supposed to do, you can sit back knowing that you were the one and only person responsible.  You can enjoy the kudos that your application receives and you think “Man, I’m a great developer”

What’s Horrible About Being a Singe Developer

No Guidance – When you start a project, it’s a little like being pushed out of plane (with a parachute…most of the time) over some wilderness.  When you land, you have to find you’re way back to civilization.  If you’re lucky, you know the terrain or at least have a compass.  Other times, you feel like you’re stuck in the wilderness, just struggling to survive until you can find a trail that will send you back to civilization.  And since you’re alone, there aren’t even kindly strangers you can ask on your way.

Responsibility –   You own the application.  But suddenly, instead of being the paragon of software development, it’s started acting like Frankenstein’s monster crossed with HAL.  And it’s ALL…YOUR…FAULT.  Remember that twisted code in the dark places of the program?   You get to fight that monster all by yourself.

Demoralizing– When you feel like the bug reports are coming in at a rate greater than you could even create them in the first place, you’re saying to yourself “How could I have missed that?”.  With each new bug report, error, or complaint that it doesn’t do what the user wants, you begin to think “Man, I am the worse software developer in the world!  Maybe I should take up a different line of work…”

So Is It Good, Bad, or Somewhere In Between…

My personal feeling it’s neutral to somewhat bad to be a single developer.  The biggest problem for me personally is not being able to bounce ideas off anyone else.  And when you’re treading new technical ground (at least for yourself), it can be frustrating and demoralizing.  When I went to college, object oriented programming was not widely used in industry.  Now, I find myself playing catch up.  I’ve been working on learning object oriented programming because I’m work in languages that require it.  But there are lot’s of things I don’t understand.  I need a mentor or at least someone I can go to for advice.  That’s one of the reasons for this blog; not only is it my chance to document my learning, but to make contacts and learn myself.

Another reason I think that being a single developer is tough is that you can get pegged as being someone who wants to work by himself/herself and can’t work in a group.  I’ve had two interviews where I was asked if I could work other people.  I didn’t get either job, so I have no idea if that was part of the reason or not.  But in my heart, I think it was a factor.  In both my current job and my business, I would LOVE to not be the only one.  But management at my job decided otherwise and I don’t have the money to pay anyone else. 

So Now What?

I plug along.  I follow the best advice I can get from the Web, from books, from magazines, just about any source I can find.  I look at new technologies (.NET with LINQ, Windows Presentation Foundation), new methodologies (Agile), and just good old rules of thumb and I try to adapt them to my own use.  I really think that someone should work to adapt some of the widely used methodologies like Waterfall (yes, I know it’s evil) or Agile and strip them down to what’s manageable to a single developer.  Because I’m sure that I’m not alone out there.  I’m sure there are many developers stuck by themselves, either at a regular job or their own business endeavor.  It can be lonely out there, but to me, in the end, the result is the reward.  Seeing that shiny application in use and hearing a heartfelt thank you from the user is the best result.