|
Adding onto this, you should always use the lowest tech solution possible if it satifies the problem. Sometimes that solution is basically pen + paper + a whiteboard. Or installing dropbox. Othertimes it might be a google spreadsheet, or a wordpress site, at the end of the day the solution should be simple and straightforward if thats what the problem is. More pipelines / processes just means more headache to end users (and you), and more things to break. I had my fair share of coordinating events during school for science competitions. One event we had was spread across campus and in areas with low wi-fi coverage. Our coordinator wanted all the results managed by google spreadsheets in real time. At the end of the day, it was completely unnecessary for logging results (PC problems, typing in broad daylight sucks, no power outlet for laptop, no wifi coverage, etc) and resorting to a piece of paper to write down competition results got the job done much smoother. I've had to do IT for alot of my friends and families. The last thing I ever want to do is introduce them to a new piece of software, because its just going to be more work for me tweaking it to their liking and them learning a new software package. Not only that, they are just going to eventually install a virus anyhow. Then I'm going to have to reset their PC a year later, regardless of how well I teach them about safe practices on being online. There's a japanese philosophy that revolves around these points made above, called LEAN (also, this is what agile development is based on). One rule is you adapt well proven methodologies and workflows first, unless the benefits of using a shiny piece of tech far outweighs its cons and risks. Another rule is to listen and understand, before you jump to conclusions. A 3rd rule is to eliminate waste, in development this is generally your buildprocesses / shiny tech / reliance on too many libraries. TL-DR . Go low tech as much as possible if its an option. If not, the benefits of shiny tech need to outweigh its cons / risks. If you do pick a software package, pick one that's well adopted, easy to learn, and fits your use case. |