Should I push my fledgling programming work out of the development nest myself?

Question

I create new programs for internal use within my workplace of over 300 people. I largely work alone and pretty much have carte blanche to create or improve anything. My boss and other superiors have been happy with my work so far.

The issue is that in my small department, we don't have a process for testing new work, approving it and putting it in production. Our previous Senior Programmer has left and I am effectively the replacement. In the past, not a lot of new applications were created, but I have been developing new things for years.

I was waiting for my boss to review and accept things, but over time I've just started putting new applications on the production intranet after I tested them. There they sit, because no one knows they exist. I am uncomfortable sending email to "all personnel", but did that recently when someone suggested it.

Do I need to be proactive in pushing things out to everyone at my workplace?

Answer 1

tl;dr

Should I push my fledglings out of the nest myself?

No. You should find like-minded people who are invested in your applications to help you nurture and support them throughout their entire lifetime :-)

---

Long Answer

If no-one knows your applications exist, you might want to ask yourself why do they even exist in the first place? :-).

Making a software product successful (even in internal one) isn't just about writing code that works - when you get an idea for a new tool you should maybe have a discussion with the owners of the relevant business area or process it's aimed at improving and find a user champion amongst the target staff base before you spend any time writing it.

You can talk to them about what benefits the application might offer (e.g. improved productivity, new business capabilities, better governance, etc), and they might be able to make suggestions on how to refine or improve it.

Or better yet, solicit ideas from your user base about what applications would provide the most value for time and effort spent writing them - they might even suggest a completely different tool that has more value to them right now. They'll also have the relevant business contacts and subject matter knowledge, and will be able to suggest the best way to connect with the target users and organise training.

In short, instead of flying solo in a vacuum, try to build small informal working groups or project teams for each application who are invested in making it a success. You might still be the only developer on the project, but if you can recruit other stakeholders from your audience you'll possibly find they get visibility and adoption a lot quicker.

You might need to get your boss on-side with this first, but if they see it helps you make tools that are more valuable to the business and raises the profile of their team as a side-effect you should be able to get them on board pretty easily.

---

Personal experience

A long time ago I was a solo developer embedded in the Marketing Department of an international investment bank, responsible for development of a set of add-ins for the Microsoft Office suite that provided interactive corporate branding and page layout tools for internal documents and client pitch books.

Although I did pretty much all the technical work, that was only a small part of the project - over time we built up a large network of international stakeholders who informally helped us outside their regular duties, including regional desktop support teams to deploy the system and troubleshoot end-user issues, trainers to produce manuals and training sessions (including one presented to all new global starters as part of HR induction), and a team of trusted early-adopting users who did testing and gave feedback on updates before we released them, as well as creatives / brand designers, and product enthusiasts / evangelists at multiple levels of the corporate hierarchy from analysts and secretaries all the way up to endorsement from C-level board members.

It was effectively an informal "shadow" startup (think SkunkWorks) within the main organisation - it was totally a team effort, but we were able to get recognition for our work within the company well beyond our official status and the system ended up being installed as part of the standard build for about 10,000 corporate workstations worldwide as a result and used by hundreds of people every day.

If you compare that to what would have probably happened if I'd just uploaded the add-in to the corporate intranet and sent out an email, you can see that perhaps you shouldn't just "push your fledglings out of the nest yourself" - you should find like-minded people who are invested in your applications to help you nurture and support them throughout their entire lifetime:-).

Answer 2

You should be careful of putting things into production if your manager/superiors haven't already approved them, because:

• a bug/issue could have significant repercussions for you or the business
  • Consider this: a tool you've created starts hogging memory or gets stuck in a loop and crashes the IT infrastructure in your business, your boss gets a call and finds out it was some tool they've never heard of, they find out it was your tool and they hadn't "signed off" on it (either verbally or written), that could cause friction and you could end up being reprimanded in some way
• your manager could (either randomly, because of ego, stress, bad day, etc.) take issue with the fact they haven't been involved and weren't consulted
  • again that could make it difficult for you at your workplace Of course there's any number of reasons I could put here and I'm not saying these things would necessarily happen, but they're possible outcomes... With these points, the blame would ultimately fall to you if the manager hadn't reviewed or signed off on the tools use - ultimately though, you need a process to protect you/the business at the very least; at the end of the day, if there's a problem you would be able to say "I followed the process, but there was a mistake and that mistake was missed during the process", so the process would take the blame and would then need improving and so on.

Alternatively

I would instead encourage you to consider proposing this process/framework.
You mention that the previous Senior Programmer left, making you the de-facto go-to; proposing the new process would be the sort of initiative that would bode well for you:

1. Experience in the software development lifecycle, and implementing new process in the workplace would look great on a CV
2. It would raise your profile within the business by making you look like a proactive member of the business/team
   • this could even boost your chances of being promoted to the Senior Programmer, which in turn would mean that the business would pay you more, and potentially hire someone with less experience for you to train up, which would a
   • You also have some good arguments on your side for increased pay if you have an annual performance review

In the short term

Obviously creating that process would take time, so in the short term I would suggest you discuss with your manager about the tools you've created. Ask them "what they would do" with those tools, they (or you) may suggest sharing the tool with a certain team/group at first (like a Beta test).
If you tell a small group about a tool first, tell them how to use it to get some feedback on it/documentation/training material before announcing the tool to everyone in the company.

Some questions

These are more rhetorical questions you should ask yourself which may help guide your thinking:

1. Do you have documentation that you could share with people about how to use the tool(s)?
2. Is there a section on your Intranet that has links to these tools?

• And would you be able to but an icon next to them to highlight that they're new? (This may get a few people in the business using it)

3. Does your company do a bulletin email every month/quarter? If so, you could have a section in there talking about some of the tools?

• In a previous company, I gave a couple of talks at monthly company meetings on internal software tools. I found this was far better than being on the quarterly bulletin because people actually paid attention (rather than skipping the email altogether!)

Answer 3

There they sit, because no one knows they exist

... until one day they learn about them, introduce them in their process and suddenly your helpful applications become critical.

You then have possibly half-baked^* applications that need to be seriously maintained and then you get zillions of requests for updates, features and whatnot.

Just make sure that you really want to be in that boat

---

^* or not, this is not a criticism - I have plenty of such really neat apps that I would like people to use but then I am doomed because of the above.

Answer 4

Do I need to be proactive in pushing things out to everyone at my workplace?

The obvious answer is to ask your boss if it's okay to release your work into production once you feel that it is ready, or not.

I suspect the answer depends in large part on the applications themselves - what they are intended to do, and what are the ramifications if they fail.

If the applications don't update anything, put just produces non-critical reports, then perhaps an informal process is appropriate. But if failure of the application could cause important business failure or expense, then it might not make sense.

Either way, this is probably a process decision you shouldn't make on your own.

Answer 5

Yes/No depends on what your boss wants.

Speak with management and ask what to do. But please, just be sure they are flawless and are not going to introduce random bugs or problems in the process. You don't even have an environment for rolling out applications and testing them, that is suboptimal.

Give them the options you have, which are :

• A general email telling people where the software is and how to use it, this will (by my experience) lead to fewer people actually using it, and keep on using it.

• A small training for each application along with an explanation of how it should be used to reduce time spend doing X or Y, paying special attention to those that will use the application all day, every day. Teach everyone how to report a bug.

Answer 6

Having once been in that situation myself, I came up with a solution. Once I was happy with an application,

• I would document it,
• Place it in a an accessible location
• Then email all the staff
  • Telling them about it
  • Informing them to expect a few bugs
  • Requesting them to test it and provide constructive feedback.

After a while I noticed that the same two people were willing to test and provide feedback, so I focused on them and involved them a little in teh specification of future applications.

Answer 7

What you are doing is not the most optimum thing in the world, but also not quite unusual. There are many topics to discuss here, but as you are relatively alone right now you should worry about yourself right now, and come to conclusions about this. Try to answer these questions for yourself, and if you have a useful answer, that will tell you directly (and better than us) how to proceed:

• What happens if you become ill or are on vacation?
• What happens if you leave the company (this is a different question than the previous)?
• What happens if users get really dependent on your app, and if they require critical, immediate changes/adaptions?
• What happens when this occurs for two different apps at the same time, with both of them not being trivial changes?
• What happens if/when you become bored, annoyed or overwhelmed by your work?
• What happens if you need to make changes which go beyond your capabilities (i.e., widely off your expertise)?
• What happens if data gets permanently lost, assuming there is some persistent storage?

On the one hand, none of these kinds of problems are caused by you personally, necessarily; but you will be the one suffering personally.

Solutions could come in many different forms (for example: create a team surrounding yourself, at least one like-minded person, optimally at least two; avoid persistent data at least; avoid putting out apps with any kind of critical impact, at the very least unless there is a well-defined stakeholder/owner higher up in the company; or plenty of others). In every case, you are not the best person deciding this, but this needs to come from management.

If management is silent, then you have thinking to do on your own; imagine scenarios and see if you want to live through them.

Answer 8

Maybe, depends on the managers personality

As I understand it, your job is to create useful tools and thats what you do. The problem is, your manager kind of ignores those, but does not complain either when you actually introduce them to production.

I think this is not uncommon, the manager is probably not the person that will use these tools, so he really is not in a good position to judge if or when it is a good idea to do that. He might not even understand what they do and what the purpose is. So he moves that mail into the "later" folder and forgets about it.

So what you can do about it depends a lot on the personality of the manager, does he like employees that show initiative or does he feel the need to decide everything?

Depending on that I see different routes:

• go the safe route, wait for the managers approval (might never come) and do other things in the mean time. You don't directly risk anything by this but probably also are a lot less useful to the company, also this can get frustrating.
• Press the management to make a decision, remind them with mails or in person. This may get you results, but likely will be seen as annoying and when pressed to a decision "no" will more likely be the answer, just because thats the safe and easy answer for them. But nobody can directly blame you either way.
• Don't ask, inform. "Hey, I have this new tool for transmogrifying the flux capacitor matrix ready, when theres no reason not to, I will roll it out to production next tuesday. Have a nice day". This way it defaults to a "yes" if he ignores you and still nobody can blame you for doing it without telling anybody.

If the manager does not like initiative like this, the last will likely result in you getting told to not do this again and ask and wait for permission the next time. You might even get yelled at if this is REALLY not liked ;)

But if they are silently fine with what you are doing this will most likely in success in my opinion. And if they are suddently not fine with it anymore, well there is a paper trail protecting you, they were informed.

What other comments said about documentation, getting more people into the boat etc still is a good idea of course.