thoughts_on_corporate_tools

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:31 +0000

2015-09-24 - thoughts on corporate tools

recently there was quite a discussion at work on tools. i'd like to share my thoughts on that subject. i've worked in quite a few places so far, and i see these issues reoccurring over and over again.

the problem

corporates tend to use custom (either in-house developed or bought from company no1 ever heard of) tools for everything they do. in place i work, windows is the official platform, but there are quite a few Linux users as well. the problem is each time new tool is introduced, no1 checks for linux compatibility. by the end of day, as you can imagine, most of them do not work, or work in a very limited manner.

an interesting class of tool is ones that do work in both environments, yet are either outdated, or there are commonly known and accepted replacements, that do far better job. as an example svn vs. git could be used. vast majority of ppl i work with prefer git (or other DVCS), yet until very recently svn was the only official one. if you used other things “underneath”, this was a tricky thing to keep it running – staying low profile was a huge helper… ;)

the funny thing is also how these tools appear – out of thin air. you just get a brief information that from day X new tool Y will be used for Z. on the other hand there are users (mostly software developers and testers) who have their needs and expectations. ppl that do know what they want to use and how they want to use it. there used to be similar system in Poland few decades back, while we were part of USSR – it was called planned economy. all the decisions, regarding every aspect of market, including prices, were made on top, and everyone had to comply. sounds very much like our “tools problem”, don't you think? for thous unfamiliar with polish history – planned economy didn't worked out that well… ;)

a different way

reality shows that ppl have a great potential for self organization. in Argentina, around 2001 a huge economic crisis arose. many ppl lost their jobs and many factories declared bankruptcy. what looked to be the end, for many was merely a begging. in some cities ppl organized themselves to continue production in abandoned factories and continue to sell their products to earn for living. in worked out very well, and many of these factories are still operational today and have better financial results than they ever head. for more details i highly recommend following reading:

Argentina is obviously not the only place in the world it happened. it was the scale though, that brought ppl's attention.

i've once read a series of interesting articles on management – “how it's done in {Google,Facebook,Amazon}” style. the conclusion was: get a bunch of smart ppl, give 'em task and do not interfere. that's also how two pizza team idea arose. small teams can achieve great things, when left alone. i believe this idea applies to tooling as well.

some ideas

what's the point of complaining, when you do not provide an alternative? i thought about what could be done and how could it be brought to life. here they are, one by one. they are more or less in a “self-organizing” spirit. from my experience, this tends to work the best, as one size does not fit all.

self-provided tooling

if you need a tool – just use it. in software development there are plenty of tools, that are high quality, yet free. just join the club! :) as long as a company does not need to pay money for it, or release created software's source publicly, most likely no1 will bother. if you think this will benefit you and your team team – go and get it! in fact, you can “legalize” them in your company – if they will work, you can report their usage and then paperwork departments will be happy as well. if some1 will cause problems, you can always provide an estimate for “rewriting things from scratch, on our own”, showing man-months/years of development. forcing others to make such a decision will scare away grumblers.

each project use own tools

one size does not fit all. the same team, for different project may use different tooling, of their selection. consider microservices architecture approach – no problem having 5 different technologies for 5 different components. once they are clearly separated by an interface, deployed separately, who bothers what happens under the hood? this concept lays deeply rooted in modern architecture styles. i can only hope it will continue to grow in that direction.

towards free-market

a side effect of a good architecture is set of libraries, that are independent enough to be reusable by others. put your project in a publicly visible location – if some1 finds it helpful, let them use it! you need to provide support for bug-fixing any way (note: they will test your code for you, during every day usage!). if they wish to change something – it's their call – fork-and-go, i say.

no "common cores"

most of the big projects in enterprise environments, that i have seen, started with creation of “cores”/“commons”/“foundation class”/etc. these usually are wrappers for things that do not tend to change, implementing typical functionalities that you can take of-the-shelves in open-source world or other means of reinventing the square wheels. if you can avoid them – do so. they will slow you down from day 1. they tend to have extremely limited and fixed working scenarios, often have been created years ago and does not comply with modern standards and provide their own restrictions, you might not be willing to live with.

having “commons” looks nice on the paper, but the truth is there often is more fuss around making it work, fixing a bug in godforsaken component, that no1 touched in years, and especially when asking for a new feature or a change request. since these components are “common”, if their usage was enforced long enough, you'll end up having a central architectural component, that is hard to move/modify, because so many different projects may depend on corner cases of its behavior or on sum undocumented APIs and side-effects.

provide interfaces – the implementation should always be easily switchable.

no in-house by default

making a tool tailored specifically to your needs is not necessary a bad idea. keep in mind however that most of the time you will be inventing a square wheel as most likely there already is a tool that does the job right. it's just a matter of finding it.

i've worked for companies that had even such a simple thing as bug tracking implemented on their own. it was unintuitive, had horrible web UI and no API to build upon. literally the worst tool ever made for bug tracking. yet company continued to work on it wasting man-years on development and probably even more when ppl had problem to find their way through the tool. lack of features resulted in “usage conventions” and “e-mail bug fixes”, that were tracked only on ppls e-mail boxes.

forget about “own tool”, unless you can really prove, that tool you need has not been invented yet and any invented tool cannot work for you, even with in-house plugin to solve your problem.

opt-in support for common things

if many teams use the same tools, it might not be a bad idea to provide official support for them. say if 30% of developers use gitlab, why not provide support for per-project gitlab instances and save ppl time to create their own? the main difference is there is no need to use this service – if unused, it will be suspended/removed. if ppl do use them and they are happy, it will continue to grow. which leads us to another point…

support for devs, not devs for support

it is very common for IT support in enterprises to suxx! in one of the companies my friend worked, IT's target availability was as low as 90%!! imagine – one day every two weeks everything could go offline and it would be fine! even though, the target was so low, IT did not make it up to the task! it is like developers were testers for IT department, instead of IT department serving as a provided for developers.

what is being supported starts with ppl. if they are willing to give away control over some tools to IT and they are happy with the support level, everyone gains. if IT support will not do they job, they'll become penny less and its work will naturally be distributed to projects' insiders, until things return to how they should look like.

good IaaS-style support

there is one thing that should be provided by IT and would be done well – infrastructure for work. if you need a server, one call should be enough. you get machine, you get a root and you can do whatever is needed to keep dices rolling. this will provided a good ground for doing everything else.

if even this cannot be reasonably provided by IT, the only alternative i can think of is to give projects an extra budget to but the hardware they will run on. this is a last resort option, as this will cost company significantly more, but it that's the price to pay – so be it. paraphrasing old song – “work must go on”. ;)

obvious or not?

at first the whole idea of developers selecting their tools may sound strange to some. to make it clear, think about what would it be like, if the situation was reversed. now company is being commanded by developers and everyone need to comply. i wonder how would high level manager, and other non-technical employees react to uninstalling power point on all machines and providing them with beamer with makefiles to build their presentations from source code, in command line… or maybe replace their beloved outlook by mutt. well – the nice thing would be that some of them would probably finally learn to stop using top-posting. ;)

any way – you can imagine how much confusion would it cause among them. what a productivity disaster would it be… yet the same thing happens over and over again with tools for developers and for many it seems ok. so why not let developers choose their own tools instead of micromanaging them?

when_order_does_not_matter

anonymous@undisclosed.example.com (Anonymous) — Tue, 15 Jun 2021 20:09:31 +0000

2015-09-24 - when order does not matter

after quite a long break i finally share presentation materials from NDC Oslo: presentation and recording. unfortunately first few minutes of the recording are lacking video and video is in a different format. fortunately it is still readable, so one knows what's going on. :)

during presentation i show how to implement a C++ function, that can take arguments in any order, and provide arguments for those, that are not given. for instance having function foo:

void foo(std::string abc="test", int answer=42, std::vector<double> values={1.0,2.0});

instead of having code like this:

foo(std::string{"other"}, /* how to provide default value here?! */, std::vector<double>{1.1, 2.2});

one can write something like this:

foo(std::string{"other"}, std::vector<double>{1.1, 2.2});

…or like this:

foo(std::vector<double>{1.1, 2.2}, std::string{"other"});

…or like this:

foo(std::vector<double>{1.1, 2.2});

…etc. i think you see the point now. :)

why would you need something like this? in fact it proves to be very useful for testing frameworks, when you have common function calls, that can take many arguments, but typically users pass only some of them, keeping remaining as default/non-interesting. having such info, one can write nice comparators, that allow to ignore non-provided values! this make users' code very clean and, as a free lunch, does not require them to remember “the order” of parameters.

i was thinking about writing an article about it, but taking into consideration how much overbooked calendar i have now (this is my first post in 4 months!) it ain't gonna happen anywhere soon.

BaSzErr - blog:2015:09:24

thoughts_on_corporate_tools

2015-09-24 - thoughts on corporate tools

the problem

a different way

some ideas

self-provided tooling

each project use own tools

towards free-market

no "common cores"

no in-house by default

opt-in support for common things

support for devs, not devs for support

good IaaS-style support

obvious or not?

when_order_does_not_matter

2015-09-24 - when order does not matter