[marcus_holmes]

This usually comes back to maker time vs manager time.

If you want a developer to write good code quickly, put them in an isolated silo and don't disturb them.

If you want a developer to engage with the business units more, be prepared for their productivity to drop sharply.

As with all things in tech, it's a trade-off.

[TeMPOraL]

I think that's the lesser problem. The bigger problem is the attitude of IT is wrong from the start. When they start doing something, they want to Do It Right. They want to automate the business process. But that's the wrong goal! You can spend years doing that and go all the way to building a homegrown SAP, and it will still suck and people will still use their half-assed Excel sheets and Access hacks.

IT should not be focusing on the theoretical, platonic Business Process. It never exists in practice anyway. They should focus on streamlining actual workflow of actual people. I.e. the opposite advice to the usual. Instead of understanding what users want and doing it, just do what they tell you they want. The problem with standard advice is that the thing you seek to understand is emergent, no one has a good definition, and will change three times before you finish your design doc.

To help company get rid of YOLOed hacks in Excel and such made by interns, IT should YOLO better hacks. Rapid delivery and responsiveness, but much more robust and reliable because of actual developer expertise behind it.

[thyristan]

> They should focus on streamlining actual workflow of actual people.

If you streamline a shitty process, you will have diarrhea...

Unfortunately, most processes suck and need improvement. It isn't actually IT's job to improve processes. But almost always, IT is the only department that is able to change those processes nowadays since they are usually tied to some combination of lore, traditions, spreadsheets and misused third-party software.

If you just streamline what is there, you are cementing those broken processes.

[TeMPOraL]

That's precisely the mistake I'm talking about. You think you're smarter than people on the ground, and know better how they should do their job.

It's because of that condescending, know-it-all attitude that people actively avoid getting IT involved in anything, and prefer half-assed Excel hacks. And they're absolutely right.

Work with them and not over them, and you may get an opportunity to improve the process in ways that are actually useful. Those improvements aren't apparent until you're knee-deep in mud yourself, working hand by hand with the people you're trying to help.

[littlecosmic]

In my experience, it’s often the business side - rather than IT - that tries to use a technical change to force change to the business process that they have failed to change politically… and it usually turns out that a technical change isn’t enough either.

[TeMPOraL]

Right. But it would help if internal IT wouldn't reinforce the business side in their delusions, and it starts with a mindset problem: IT thinking of itself as a department that delivers products and solutions, instead of a support force of servants meant to run around in the background and respond to immediate needs of people in the field.

[ozim]

You went too far and mixing IT with software development.

Software development delivers products, internal products and solutions that should be leveraged by business to improve rate of growth.

If you have software development department chucked into IT and make them be supporters that run in the background you are wasting potential or wasting money on their salaries.

If you want supporters make it IT only and pay for SaaS solutions that everyone is using.

[skydhash]

The problem with hackish solution is that they get put in places they don’t belong. In other professions, there’s regulation in place to prevent these kind of shortcuts.

Also, if you have ever worked with anyone trying to get specifications worked out, you’ll see that most people (including devs) rely on intuition rather than checklists and will always forget to tell you something that is critical.

The thing is that cost of changes in the business can be a simple memo. But for software that usually means redesign.

[TeMPOraL]

> The problem with hackish solution is that they get put in places they don’t belong. In other professions, there’s regulation in place to prevent these kind of shortcuts.

That's an illusion. The reality is, it's all hacky solutions on top of hacky solutions. Even in manufacturing: the spec may be fixed, and the factory line produces identical products by the million - but the spec was developed through an ad-hoc process, and the factory line itself is a pile of hacks that needs continued tuning to operate. And there is no perfectly specced out procedure for retooling a factory line to support the newest spec that came out of design department - retooling is, in itself, a small R&D project.

> Also, if you have ever worked with anyone trying to get specifications worked out, you’ll see that most people (including devs) rely on intuition rather than checklists and will always forget to tell you something that is critical.

This is the dirty truth about the universe - human organizations are piles of hacks, always in flux; and so is life itself. The sameness and harmony we see in nature is an illusion brought on by scale (in two ways - at large scale, because we live too short to see changes happening; at small scale, because the chaos at biomolecular level averages out to something simpler at the scale we can perceive).

Order and structure are not the default. It takes hard work to create and maintain them, so it's better be worth the cost. The prevalence of Excel-based hacks in corporate is a proof positive that, for internal software, it usually isn't worth it, despite what the IT department thinks.

> The thing is that cost of changes in the business can be a simple memo. But for software that usually means redesign.

Which is why you shouldn't be building cathedrals that need expensive rework every other week because of some random memo. Instead, go down to where people work; see them tweaking their shovels, take those shovels and make the tweak they want the proper way.

[skydhash]

We could do this. And if you take a look at some solutions like the old VisualBasic/Delphi/Unix scripts, the philosophy is the same: Create small software quickly that solves some user/business needs. Systems like Java/.Net and their IDEs, as all as current mobile SDK, they run against that need.

A bit of tangent: I think the idea of coddling users is what’s leading to the complexity of all those system. We’re building cathedrals when we need tents. Instead of having small, sharp software tools that can be adjusted easily, we’re developing behemoths that’s supposed to handle everything under the sun (systemd, a lot of modern package managers, languages that is tied to that one IDE,…)

[nradov]

Actually there is no trade-off. That's a common misunderstanding. Reducing latency creates more business value than increasing productivity.

http://lpd2.com/

[thesumofall]

That depends if one measures productivity in LOCs or business impact. As always, it’s not black or white, but my experience is that higher proximity is a net benefit