3

NOTE: The information after the question turned out almost like someone who is venting. That wasn't my original intention. If someone does want to take the time to give me an answer/advice, skimming it might help.

QUESTION: I'm looking for a better way to phrse "single box development". I'm trying to take a first stab at telling my boss (the co-owner of the company who sees every dollar spent as a dollar out of his pocket) that, while it got us this far (i.e. he can't see anything wrong with it yet!), the limit has been reached.

BACKGROUND: I'm only programmer at a 40 person company. I started an LOB from scratch 6 months ago (WinForms/MSSQL). So far it's a smashing success. People that used to work until 10pm now head for the door at 6 and thank me on their way out (I know, yay for me).

I'm battling an "if it ain't broke don't fix it" attitude from people who only see the external results. I sit close to the end users (18 of them) - if something doesn't work, they all tell. If it crashes, they don't care because they walk over (50 feet at most) to me, I press F5, they show me how to reproduce it and more often than now I go, "Oh, that's easy to fix - just didn't think of that case". Five minutes later I click "Deploy", and shout, "OK, get the new version!". ClickOnce deploy makes the line between web apps and desktop apps blur.

Knowing I'm only one person, I have taken every measure to keep the use cases non-dependant on eachother. If I write code that could do "damage" if it didn't work I've tended to putting preventative measures into database triggers, thinking "this limits my worst case" - but this feels "creative" to me, and usually that's an indicator that it's not a long term solution.

Now I have to add an ASP.NET solution added to my project. I've got two products on two different platforms with two different user bases, but all accessing the same data and for related business purposes.

I need to:

  1. Remain a one person software team.
  2. Have some kind of thing with the word "cycle" in it.
  3. Keep delivering features with the same pace and reliability.

For reasons I'm sure everyone already knows (and doesn't need to tell me) I can't keep adding features and meeting deadlines while maintaining the relatively low defect rate I've managed to date.

There's NO WAY I'm going to get the kind of monetary commitment required to start an in-house software company but I can't deny the benefits of having someone right there next to the stakeholders at all times observing how the business operates and ready to tweak things at a moments notice.

So my goal is to inch towards the way the rest of the world does it, and my current step is to get at least one more machine so I can have a formal integration environment.

Improve this question
4
  • 3
    Usually the only way to sell the idea to a dollars and cents kind of boss is to demonstrate the true costs, and what you are saving him/her. If, for instance, adding a $2000 piece of hardware can save the boss $15,000 extra labor it's a no brainer. The key is demonstrating the hidden costs in the current method of business.
    – Berin Loritsch
    Mar 14, 2011 at 17:45
  • 2
    @Berin Loritsch: The other trick is in demonstrating that people leaving at 6 PM rather than 10 PM is good for the company, if they didn't get paid overtime anyway.
    – David Thornley
    Mar 14, 2011 at 18:09
  • @David Thornley, That's demonstrated by lower turnover (cost of training) and healthier employees (lowering health benefit costs). The first is the most tangible benefit.
    – Berin Loritsch
    Mar 14, 2011 at 18:57
  • Argue the virtual route. Make this machine you want to acquire the host and pitch it from that stance. Rolling back; adding machines as you grow, ability to shift resources where they are needed, etc...
    – Aaron McIver
    Mar 14, 2011 at 19:53

2 Answers 2

Reset to default
7

What does he want to do when you are implementing a significant change that needs to be tested? Not a bug fix and not a brand new feature, but a change to a current feature. The ROI on everyone waiting to use the application until it has been tested by the other users is not going to be good. Not testing is not an option. You can get a way with that for little bug fixes or adding a brand feature (it's new so they can wait for it to be tested).

It's a matter of insurance. If your app breaks for a day what will that cost?

Improve this answer
1
  • Its funny you intuited the exact scenario that caused me to write this - i've got a far-from-trivial change to a core part of the system and the best I could come up with was "come to desk the first time you need to use it" at which time i'll back up the database in case it doesn't work... I like the way you phrase it though, in terms of insurance. Thanks.
    – Aaron Anodide
    Mar 14, 2011 at 18:06
2

If he likes the jargon but you don't want to lay it on too thick then explain that your current system has a single point of failure, and that you are working on complicated new code that may needs active testing, in its own environment, to ensure data integrity.

Use the second box as a backup server too and mentioned that you've been worried about the aftermath if something were to happen to your current data / server and hopefully your boss will see the benefit. The cost of re-entering any data or losing it entirely has got to be high enough that he'll want to mitigate the risk with a relatively inexpensive purchase.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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