For those of us who work in the IT department of organizations, and who have some programming skills, we face a recurrent issue of build versus buy.
Sometimes, a dude in finance wants some fancy Excel macro, for a report NOW! Where I work, everything is needed NOW or worse still, yesterday. (Back to the Fancy dude/Excel macro) Should I search MS marketplace and buy a suitable macro or bump my head on macro writing to develop something for the annoying gnat. The above scenario is simple enough.
Sometimes, we are faced with under-performing legacy application. Legacy because that is what annoying program that is expensive to replace are called. Should we write helper application, modules, etc.? Is it right, em, to rewrite some part of the code to optimize it if the original vendors are too rich and complacent to do it?
From experience, I, with my colleagues, developed an application to do some function of the legacy app running our organization. Now, this app of ours is so large with a billion and ten modules performing all manners of functions: from generating statements to serving coffee with croissant. As you can expect from such attempts, the idea is good, but the app is far from perfect albeit better uptime and performance than our legacy app.
So every day, we get a zillion requests to develop this and that. When we send reminders that we ain’t programmers or developers, the honchos bark at us. But man, when we ask to go for trainings, developer conferences and buy books and materials, all of a sudden, the organization ceases to develop applications. What a life!
For me, I think organizations can develop little widgets here and there but should not dabble into app development unless it is ready to commit resources to it. Workers turned emergency developers usually write horrible codes with documentation and continuity equal to zero. The security implications of organization that rely on such home brewed apps is not too hard to imagine.