Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

For the best part of the last decade I have been working as the only IT guy in tiny company. At it's peak this company employed about 8 staff. It's now down to 4, one of them part time. So the going is tough - but given its size it always has been. I enjoy working with the people there which is why I am still there and my employees have never blamed me for poor code or anything. They are entirely supportive of my work.

However I struggle intensely with the whole "do it properly" idea. For the first 6 years of working there I largely worked on our in-house web based CMS. This is from just before the times of Ruby On Rails setting the tone as an example of an efficient web application stack or Wordpress setting the blogging standard.

At the time we surveyed the available options and decided that nothing offered what we wanted with respect to standards, accessibility and usability (big mistake in hindsight, but such is life). So we (read I) set out developing our own CMS. The code I churned out is just awful, awful stuff. It got written in a haste as we were always playing catch-up with features or hastily meeting client deadlines. Our system became slower and unpredictable, changes difficult and so on. As you'd expect really.

I got more and more frustrated as I am aware of TDD, refactoring and so on, but there just never seemed to be the time. Also note that being the only IT guy also means maintaining the office network, providing desktop support, technical support in writing proposals and last but not least maintaining our servers and the 50-60 websites that run on them using our CMS.

I've rarely felt confident to even approach TDD as it IS a lot slower in the first instance. This has been constant source of real, and I really mean REAL, deep frustration. I know I am doing it the wrong way, but there appears to be no chance to do it the right way. Maybe I am just too weak, not a risk taker. I don't know.

But how have others coped in such a situation?

I am frequently at the point of throwing in the towel. Probably would have done if there weren't the tiny issue of having to support a family. Moving jobs would be difficult as it will likely mean moving countries (but that's by the by).

I sometimes wonder whether this whole TDD stuff is something which is almost the exception rather than the norm. We've recentlty jumped ship to Wordpress as we will never be able to get to that quality with just one IT guy. Having peaked into the code base, Wordpress doesn't look much clearer than what I coded up, and lets not talk about many of the plugins. But it doesn't seem to matter because Wordpress as a platform is rock solid, well documented and obviously has an outstannding QA procedure. And since moving to Wordpress most of my work appears to be around integrating plugins and coding up a few lines to hook it all together. Not much development at all really. Which leaves me with even less opportunity to do real satisfactory agile development.

I am particularly keen to hear from others in similar situation to me. Do you just write it off as part of the life of a developer in a tiny SME? I've really lost confidence in my ability to develop software as opposed to simply hack it all together. How do you go about doing best practice agile web development when you're the only guy on the team.

EDIT: good answers so far. I'd like to hear from others who are or have been in similar situations. ie working as the sole IT guy in a very small company. How do you cope with the constant demands for your time with no-one else to realistically help you out? Thanks.

share|improve this question
By using WordPress you essentially get a lot more hands to do the work needed. Consider whether you can write a migration module to convert data for your current CMS into WordPress. –  user1249 Feb 11 '12 at 10:50
Yeah, I am already doing that. But my point is more about how to do "agile development" with all its trappings in such an environment. Is it just wishfull thinking? Is it me that's the problem? –  ZweiBlumen Feb 11 '12 at 10:55
If you do ever leave this job, I feel really sorry for the next person. –  David Wallace Feb 11 '12 at 11:04
@DavidWallace Fair point, that's also why we're moving to wordpress. I don't wish our current in-house CMS on anyone. I should add from the end user perspective it is actually not all that bad, perhaps bordering on being quite good. Hence no complaints from the owners. But technically it is unmaintainable. –  ZweiBlumen Feb 11 '12 at 11:24
@ZweiBlumen You say that you don't have time to do X but as the only IT Guy are you not the one setting your schedule at least in terms of of estimates? You need to be more realistic about how long something is going to take and let them know up front. Don't undercut your time. Also if you are trying to expand your knowledge on something its not always the companies responsibility. You can "bone up" an TDD on some play projects on your own time and then easily integrate them into your day to day. –  Ominus Feb 13 '12 at 20:46

4 Answers 4

up vote 1 down vote accepted

I'm the sole IT guy in Helicopter Charter company of about 100 people, I do all the support, administration, installation of new equipment (except specialised stuff like phone systems and Cisco routers). I also wrote the companies CRM & Booking system and various systems that are needed for the day to day running of the company.

I totally sympathise with your situation, my company is not really willing to invest in higher quality, partly because what I wrote works pretty well and partly because the investment goes into ensuring safe operation of aircraft. My systems aren't safety critical. The flip side of this is that the company recognises that what I write isn't going to be perfect, just good enough.

I'm lucky, because the company I work for is a friendly place and you can have open discussions about problems.

I've been looking at TDD, but at present I don't know enough to really know how I would implement it. I don't know how I would write tests on things like jsp's or database accesses for example.

We (you, I, others in similar situations) do, however, have couple of advantages. First we probably know A LOT about how our companies operate and so undertand what is being asked in more detail than, say, a contractor parachuted in. Second, as analyst, designer, programmer there is less chance of misunderstanding what is to be produced.

So I try to get the basics right, do thorough analysis of any bit of programming requested so that you really understand what needs to be done (I've got quite good at asking "stupid" questions). Take time to produce a good design. Follow good programming guidelines. Get the person who requested it to test it to make sure it does what they expect.

If I think of anything else I'll post a comment.

share|improve this answer
Thanks for sharing this. There's some good viewpoints in there wrt getting basics right and understanding the initial requirements. Certainly sounds like my situation a lot. –  ZweiBlumen Feb 13 '12 at 11:06
I decided to accept this answer because it most accurately summed up my situation, but from a different point of view. eg having an intimate understanding of the requirements, asking "stupid questions" and so on. At the end of the day it is really about the end product, not the code. –  ZweiBlumen Feb 16 '12 at 12:07

You are essentially in a situation where you need to tame the legacy system you already have before you can start considering what to do next.

Fortunately (for you) others have been in the same situation before. A very good book on the subject is "Working Effectively with Legacy Code" by Michael Feathers (ISBN 978-0-13-117705-5), which has a lot of suggestions on what to do to tame your current codebase. An early paper hinting on what is in the full book is http://www.objectmentor.com/resources/articles/WorkingEffectivelyWithLegacyCode.pdf

Additionally for new code you can use TDD. Writing tests first, will make your API's simpler, and the underlying code more straight forward - simply because you need to find out first how you will call the code by writing the test of if the result is right. Try it. It is one of the most powerful methods I've known so far.

share|improve this answer
Thanks for the link. That book is on my "wish list" at Amazon, but it's nice to have an overview of it. –  davidhaskins Feb 13 '12 at 14:46
The money is well spent. –  user1249 Feb 13 '12 at 22:52

When you get used to TDD it can be almost as fast as developing without TDD. If your writing small tests that test a single piece of functionality the test driven part becomes a kind of hybrid of documentation and "sketching"... Lets say you want some code that parses a string to a date; your test might look something like:

var date = new DateTime(2012,10,10);
var parsedDate = new DateTimeParser().Parse("10-10-2012");

That's only 3 lines, and in doing so you've sketched out the usage of the class/method/etc you are going to build and you have a unit test for it. If your unit tests end up being called something like CanAddUpdateValidateDeleteClientFromDataBase then they're not small enough units and TDD will seem like a horrific pain in the backside that is more trouble than it's worth. Like all things practice will make you better and faster at it.

The vast majority of my TDD experience has been with statically typed, OO, languages with the notion off different levels of access... So I only need to test my "public" methods. If you're working with a language where everything is public it may be tempting the put a unit test round every single moving part; try limiting your test to those parts of your code that interface with other objects, etc and see if it makes getting into TDD easier.

Also remember the "speed" of TDD comes not from the initial implementation but the fact that when a change needs making you just make it and run your tests and if they go green you can be pretty damn confident you haven't broken anything. Which makes fixing bugs and adding new features much easier.

But as far as best practices go you may find that your company is too small and/or can't or won't provide you with the resources you need. If they are not offering you the time to read up and practice these skills after you have expressed how much more efficient they will make your work then the company have probably written them off; which means all you are doing is fighting an up hill battle, as well as trying to do your day job and become a better developer.

You may have outgrown your current employer if this is the case (which is a real shame if the team is your reason for staying there so long :¬[ )

share|improve this answer
I think your final sentence sums up my dilema quite well. Thanks for that. –  ZweiBlumen Feb 11 '12 at 11:41

The company that I am presently working for started out very small, and I was the only software developer here for a good long while. I have worked as the only "IT Guy" in several jobs, and as the only experienced developer in a couple more, so hopefully this will help me to answer your question from the perspective of having been where you are now.

The reality is, that there is no single definitive answer for how to "Do things properly". It really comes down to striking a balance between what the company can afford, what it needs, and what YOU need.

TDD is merely a tool. If you understand what you are doing, and more importantly WHY you are doing it, then your tools will be useful to you. If not, then you won't be helping either yourself, or your company. With BDD, TDD, and other test-first approaches to development, there is a perception that everything takes longer to do. This is because you are borrowing against the future. When you test first, you are acknowledging that you are wearing an up-front cost in order to buy time against a future where you will need to fix problems in your code. Those fixes will come at the expense of other features. Every bug found and needing to be fixed is waste in terms of resourcing, and ultimately your budget. Every problem left unchecked and unresolved is a technical debt that will continue to accrue until your company decides to do something about it. So the reality of test-first is that you don't take longer to do things, you instead apply your bug fixes up front in order to reduce the maintenance needed later, and overall you take the same amount of time - more or less - to both implement code, and fix problems, and more importantly you put off the need to repay your technical debt in the short term, and possibly reduce the impact of the debt in the longer term.

As I said, testing first whether you TDD, BDD, or any other "DD" is a tool. It's a single practice that should be a part of a good overall development method. It's the processes that you put in place to manage your development efforts that are the most crucial, because if your process is wasteful, then your costs are high, and your stress levels even higher. You need to understand all of the little things that cause delays. Delay's are wasteful. waiting around for inefficient red tape is wasteful. Dealing with stress is wasteful. You need to take a good hard look at your product development process, and look for ways to eliminate anything that contributes to wasted effort, wasted time, and wasted resources (aka YOU). If you want your boss to buy into this then you need to be able to show how your efforts (hampered or otherwise) both contribute to and impact the company's profit/loss each year. You need to be able to track your work, and manage your workflow, and put into a good business context how anything that causes you to waste time and incur technical debt is directly proportional to your company's bottom line.

The reality however, is that you can't always get your boss to see the forest for the trees. If you feel you are being held back considerably, you might find it better to simply look for a better opportunity elsewhere. The frustration that builds up will only fester and become a serious risk to your health if left unchecked. I'm sure your boss may have good reasons for not allowing you to do things a certain way, but if he doesn't really, or if you can't make a good case to improve your processes and more importantly if this is causing you a great deal of stress, seek help from a good doctor and/or counselor to help you deal with any stress/anxiety issues that might have arisen, and seek employment elsewhere. You'll be happier, and you'll have the opportunity to learn to do things differently. I'm speaking from very real and painful experience here, that sometimes, it's better to learn to pick your battles, and sometimes it's better to simply withdraw from the field.

As for how I go about best practices as a solo developer, In between work and family commitments, I write software for my own benefit. I apply very Agile practices, and I use a sound methodology learned, refined, and developed over the course of my career. That same methodology has formed the basis for the methods used in my present workplace, where with a lot of tuning to suit the needs of company and developers both, I slowly changed minds and implemented the methodology one practice at a time. I used cold hard data to swing opinion, and where I had not been expressly told not to, I did things my way, supported by tools and systems that are now so entrenched that the culture of the workplace has been eventually changed to embrace Agile processes. I made sure to convince my bosses several years ago that I was the only person qualified to verify the quality of new software development staff and made sure to review applications and interview candidates myself when they came to work with us. I made sure we hired people who could support my drive to improve the processes and systems used to write the software the company develops. I've been very proactive from the beginning and the effort has paid off. It's a case of leading by example, and giving my bosses no excuses for allowing sloppiness and inefficiency to mess up sound development principles and practices. They hired me to do a job, so I made sure to have autonomy, and accountability.

So in short, be proactive, set the example for how to work rather than having it merely dictated to you - but make sure you hit all of your targets so they can't complain! And apply industry accepted best-practices while measuring your performance and always showing what you do in light of how it affects the company's bottom line. Get your processes right first, so that you can manage the technical debt you will incur later, and look for wasteful practices that you can trim or tune to make your process more efficient.

share|improve this answer
I hear what your saying about stress. It's certainly frustrating to never be able to do things to a level of quality I would consider adequate. I like where I work, but we've never been in a position where I can truly practice new methodologies over a period of time. eg a few hours a week over a year rather than the odd day here or there. Maybe it is time to move on... –  ZweiBlumen Feb 13 '12 at 16:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.