Requirements gathering as marketing

Programmers should use requirements gathering as marketing, and I'm gonna show you how.

After months of academic study of agile, requirements gathering, use cases, user stories, domain modelling, and not being in the place to really use them, as a programmer - I'm going to put this knowledge to use, doing my own software.

How? Well, honestly, by freelancing. Did you know that all of the above skills, that relate to requirements gathering are quite similar to marketing? I'll illustrate that for you:

It all starts with the domain model. Verbs and nouns which describe the world of the user. If you put these words on your landing page, then you've achieved SEO (search engine optimization).

If you put these words in your code, you've achieved domain driven design. Better to call it - clarity of vision.

User stories? Yes, write them. Explain how your software would solve a problem. This tells a story of your product, and puts it in the user's head as a solution.

It's time to do it, right? If we don't, who will?

Requirements gathering is best done by programmers and engineers, who nevertheless rarely get the opportunity to do requirements gathering.

Based on that, I have a theory of what a software company should look like:

• It should provide software engineers with people to build software for, and to sell software to.

• It should handle the risk, and legality of the deals, and provide guidance and help.

• For juniors, it should cover for the technical knowledge they lack in certain areas.

Basically, a model where the engineer has all the leverage.

Software companies don't want us anymore. Plus they can't leverage us properly. In return, let's crush them economically :)