Comment by pjc50 | Hacker News Reader

Comment by pjc50 | Hacker News Reader

Whereas:

> The reduction of the tester to an expert translator/typist is a tragedy

> The Given-When-Then detracts from understanding and readability but provides the much prized automation through tools like Cucumber

> Instead of abstract domain models in Rational Rose

Now I see how we got into this situation. All this misery comes from the people who understand the code and the people who understand the business being different, non-intersecting groups of people.

Since the BAs can't read the code, there is a desire to construct a technical representation that they can read, representing a some kind of formal specification, and then derive as much as possible the program from that. This was the promise of Rational Rose and the whole UML project. Had it been successful, it would have reduced programmers to stenographers, "coders" in a very limited sense. As it is, in a "Rational" system of this kind, coders end up producing increasingly elaborate polyfills between the machine-generated parts of the system and the rest.

The target of this is always the "5GL" dream:

     - specify program in English
     - ???
     - automated tools transform to code

.. without programmers involved. Unfortunately we've not managed to reduce the irreducible complexity of the step in the middle.

GWT does this de-skilling to testers instead; it's effectively TDD with tests in this quasi-human-readable format that gets unimaginatively translated into programs by the testers.

The proposed solution is to do more communication through spreadsheet-prototypes. Since these are effectively programs in Excel, with all the real programming capabilities thereof, you get a real working model of the system that actually behaves like a program.

Many businesses simplify this process by then just deploying the spreadsheet to production.

(I'm not familiar with Cucumber, but it looks like a thing for constructing toy "human readable" DSLs for tests? I wonder if we could get BAs to learn INFORM?)

I haven't studied this deeply, but i see a deep irony here.

The old school business guys had a plan (or at least a wish) to get rid of programmers. Ironically, I now see the best programs being written by programmers who have no BA's (essentially becoming BA's themselves). It turns out that it was way easier to just get the BA's to talk the language of the computer, rather than the other way around.

From what I've read, the same is true in testing. The best BA's are people who are actively interested in testing, and willing to learn the language they need to best help out. You cut out the middleman, not by making translators, but by learning to speak the language natively.

As it often is, it's easier to change the people than to change the world.

Im surprised you missed it.

Businesses solve this problem by hiring and training programmers in their business model and domain.

Coders, are worthless. Coders with business acumen and domain knowledge are invaluable.

This is also why I will never work with anyone with a job title of BA. They are trying to do my job but can only do one half of it. They're a pointless bottlekneck in the system.

And no, there is no place for BAs who can code only those who do. They're called software developers.

At this point I don't know if software engineer, developer, programmer or coder is really the right term any more.

I'm more of a systems analyst. The amount of time I spend coding is miniscule and I don't think I'm alone in this.

That's a bit inflammatory... My experience with BA's is that they're like anyone else on a team. They are more skilled in certain areas, and they can provide a lot of value if their skills are used appropriately.

I've found BA's are very useful in the following areas specifically

- Communication with the market (either customers or in-market staff such as sales/support) to gather feedback about what they'd want

- Orchestrating decisions (asking all the dozen stakeholders what they want to do and arriving at a sensible conclusing)

- Arbitrating feature/UI decisions (people on the team aren't agreeing on whether we should do something or not)

- Documenting requirements (by this I mean the desired functionality that we believe customers need/want)

- Iterating and getting feedback on requirements

- there's more, but off the top of my head that's all I can think of

Sure, I as a lead developer have business knowledge and can also do the job of business analysis, but a dedicated BA will be able to spend more time doing that - increasing their skills, and freeing up me to do other things. If I take on all of the above tasks in a decent-sized project, it's going to suck up a huge amount of my time - in many cases almost all of it - so then basically I'm just a BA with a different job title. BA's are great if you learn to understand the role and how it can help a team

All of those things are what a developer worth anything to a company should be doing.

Similarly, BAs without business domain knowledge are even more worthless because of this.

I.e. consultant BAs are, as most of us know, a waste of money.

BAs are struggling to find a language to describe their business requirements in a way the programmer or computer can understand.

It's code. It's what programmers have been writing all along. That is the god damn language they need.

Given when then? If then else.

Surprise!

Ricardo strikes again. Relative comparative advantage says even if a developer is a better coder and BA, they're better off spending time coding and letting non coders be BAs to maximize overall throughput.

This assumes a BA is cheaper and more available than a programmer.

If they are cheaper, I guarantee you're going to have problems.

You're literally installing a weak link in the most crucial part of the chain.

BAs are by definition more available than developers, as all developers are BAs but not vice versa.

And given basic supply and demand they are cheaper.

Anyway read your Ricardo, you're right but wrong about the implications. Your development is an even weaker link in the chain because good developers are even rarer than good BAs.

> BAs are by definition more available than developers, as all developers are BAs but not vice versa.

Plenty of developers are not BAs. BAs are systems analysts with expertise in requirements elicitation (basically, goal-directed interviewing) and technically writing. Plenty of developers are neither systems analysts nor skilled at interviewing or technical writing.

This point is brought up in the book Domain Modeling Made Functional [1] where the author contends that F# types (including functions) is readable to BA folk and this will help the communication barrier between them and devs. I highly recommend the book and agree with that statement at the highest level, though I could see actual implementation details going out into the weeds (result & async types etc).

I know other functional languages like Idris take this approach too where the designers could declare the input/output types and as long as the implementation conforms, you have some higher confidence in program correctness (at least API contractually). Interesting stuff.

[1] https://pragprog.com/book/swdddf/domain-modeling-made-functi...

Reply on news.ycombinator.com