Still in MVP mode - but it already made some sales.
What's different about it from similar solutions is the way you can get data from an Excel file (most other companies have the JSON and CSV figured out).
It supports Excel style addressing so it's pretty flexible on how you reach for the data inside a PowerPoint template (access every sheet, every cell, named range or table to use it in merging process).
People use it for various kinds of use-cases - creating certificates, automating pricing offers, delivering employee feedback forms, preparing market research presentations and even subtitles for a theatrical play.
Two employees of a company were suddenly approached by the CEO accompanied by the CTO.
- Death or Scrum? - asked the CEO
The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.
The first one thus replied in a quavering voice: "Scrum"
In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:
- Neverending sprint planning meetings
- Daily Scrums that lasted 4 hours
- The sprint reviews
- Sprint retrospectives
- The backlog refinements
After all this the employee was only able to say: "Still working on User Story XYZ. No impediments."
The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.
"I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH!
To this the CEO swiftly replied: Death ... by Scrum
Scorch is the ultimate gaming experience. In primary school we would always finish computer science classes with a game (or a few) of Scorch. Recently I've shown this game to my kids (10 and 8 years old) and they were really excited to play it. They don't make games like they used to anymore.
So we have come full circle. That's the way we have been building software when I was starting with professional software development (this was around 2005). But the idea of doing a thorough analysis (business, technical) is a little bit older. The only people to whom this might come as a surprise are the ones who've drank too much of the "agile Kool-aid". I'm not here to bash agile and start this flame war all over again (agile has it's merits ...), but somehow thinking before doing got a bad rap recently (for reasons beyond me).
It's like software development got trapped inside of King Julian's (from Madagascar movies/series) brain with his modus operandi: "let's start doing this before we figure out it does not make any sense".
The phrase I hang on to is something thrown out by someone I used to work with - "Agile isn't an excuse not to do things". Too many organisation use "we're doing Agile" as an excuse not to do any design thinking and instead "just code".
What Agile actually is (in the most general terms) is a different order of doing things that increases the amount of knowledge you have when you do it, and reduces the chances of wasting your work. In my example, you still do the design work, but rather than doing it for the whole system at once you do it for the piece you're about to do, and then implement that piece[1].
But yes, it's nice that the internet has discovered Waterfall!
[1] Although many systems, even in an agile world, do require a degree of up front "whole system" architecture and/or design thinking.
Because thinking clearly is the hard part. I use Github copilot every day for work (and it generates decent code completion for me) and the only thing I've realised is that the major work in programming is to think clearly, and converting thoughts to syntax is not really that hard. Copilot takes off that easier cognitive workload and helps me focus and clear my thoughts. Also, does anyone know how to think clearly or does that just come with practice and experience?
Thinking, especially abstract thinking, is crucial to software development, as often (not always) creating software is abstracting real life into algorithms and data structures. Writing text in a word procesor, notepad, etc. is in my opinion first step to validation of the idea, to having at least faint idea about the complexity of the solution we would like to build.
On the question of "how to think clearly" - I'd say it's pretty individual - some people start "from the bottom", some "from the top" and others "in the middle". Experience is to know which is which and which approach suits you best.
I think you can sum it up this way: be planning heavy where it makes sense, and agile where it makes sense. There is not true one way. I'd not want to use agile to develop the formula language in a spreadsheet, and I'd not want to waterfall a marketing website for a product that is speculative. Common sense applies.
Agile and Documentation-Driven-Development can not only easily go hand in hand, I think agile is perfectly suited to work like this.
We figure out what the software is supposed to do -> We write documentation describing that -> We build the implementation -> New Requirements -> Figure out how to incorporate them into the plan -> Update the documentation -> Build the changes.
It's an iterative process, perfectly suited to agile development.
I would assume that an agile process will rely on Markdown, but then it some point does it get (irreversibly) committed to a more conventional document format.
If assume (please correct me if I'm wrong) by "conventional document format" you mean ones that do not play well with version control software like git (eg. because they may be/contain huge binary blobs), yes?
If so, at least in the projects I am involved in, all documentation that is checked into the repos remains in markdown (asciidoc is also used alot), and is only converted to non-plaintext formats for the purposes of release.
This is similar to how we build executables from our source code, but don't check in the resulting binary files into the repo.
Yes, by "conventional document format" I meant something in the Microsoft crapiverse.
Keeping it in markdown/asciidoc sounds great if you can make it work. Is your work in technical environments ? Where people have no expectation of using MS Word ? And those users that need fancy features like footnotes can learn how to use them and then retain that knowledge and use the features without inadvertantly document damage ?
I ask because I worked TC in a software firm targeting Microsoft platforms, so they relied on Word (and Sharepoint), and were resistant to ideas of XML and structured documentation, and Markdown never even raised its head.
>somehow thinking before doing got a bad rap recently (for reasons beyond me).
I've seen plenty of software devs engage in detailed forward planning for a future that would be utterly different from what they expected.
Best case this rendered all that forward planning moot and a waste of time. Medium case is they did a lot of pointless work. Worst case they technologically straitjacketed themselves and dug multiple holes they couldnt extricate themselves from easily.
Then they'd pick themselves up and do it all over again thinking that if they (or more usually somebody else) just managed to predict the future better then this kind of shit wouldnt happen. E.g. those idiot PMs just need to provide better requirements.
It's a hard rut to get out of because in so many other spheres of life forward upfront planning is critical and the future IS predictable. Software intuitively feels like it should be too. But it's the exact fucking opposite of that.
This is, at least, why certain kinds of thinking before doing got a bad rap with me.
Sounds like a problem with the execution instead of the technique.
The alternative to thinking before doing is wandering aimlessly, which really isn't likely to steer you where you want to be.
We basically developed whole-ass treatises (and some unhealthy cargo cults) around people saying that the observe -> think -> do -> restart loop should be small and leave space for adjustments between each step.
> The alternative to thinking before doing is wandering aimlessly, which really isn't likely to steer you where you want to be.
When I was a kid, we topped over this hill on the interstate, and way down in the distance there was an overpass across the road, with straight road from here to there. And I wondered how my dad could aim the car so well that it would go under that overpass way off in the distance.
Of course, now I know that he didn't do that. He didn't even try to do that. Instead, he steered the car.
The alternative to thinking before doing is not wandering aimlessly. It's steering. It's knowing where you're trying to go, even if you don't exactly know how to get there, and having an initial idea of how to get there, and then starting to go there, and adjusting as you find obstacles that you didn't know existed, and as you find that your aim was off.
Recommend revisiting Mr. Stoll's book - 'Silicon snake oil' (1995). It shows how much people who are inside the revolution can't see that it's the revolution. I think he got it wrong with everything the internet would become.
Mr. Stoll wrote something along the lines:
"Some people who are offline feel that they are cut off from some very important aspect of the present day. However, only in some ways everyday life requires either computers or access to digital networks. They are irrelevant to cooking, driving, receiving guests, talking, eating, walking, dancing and gossiping. There is no need for a computer to bake bread, play football, sew a bedspread, build a fence, recite a poem or say a prayer."
In EU we had a discussion about link tax and some related areas regarding remuneration for content providers by content distribution platforms (search engines - prominently Google and social media sites like FB, Twitter, etc.). Back then I was strongly against this new laws as some of the newly proposed regulations bundled with link tax I considered potentially harmful for e.g. opensource software managed in GitHub repos.
When I think of the link tax now and after reading this rant defending FB, I lean towards the link tax.
Quotes like make me shiver:
"First is the link tax. This is fundamentally against the principles of an open internet. The government saying that you can't link to a news site unless you pay a tax should be seen as inherently problematic for a long list of reasons."
I don't think we should put FB and open internet in the same sentence. Sharing the news is available all the time, through e-mail, slack, SMS or any other mean of electronic communication. It has just stopped being available through FB (a private, global corporation) who will STOP benefiting from it.
What service in their right mind would link to any content that requires payment? Do media organisation think their content is so great that people will pay just to link to it? Links drive SEO, charging for them is the equivalent of shooting yourself in the foot.
This can only work if governments force companies to display selected media links and then charge them for it. It can only work if governments force search engines to alter their algorithms to preference media organisations and charge the search engine in the process.
It is the worst piece of tech related legislation conceived in a so called democratic country, the fact that its even progressed to this stage is mind boggling.
I think the issue is that in many cases it does not bring traffic to the news outlet : people read the title/summary which is shown by google/Facebook, and don't click on the link.
News outlet therefore assume that it's unfair, since they don't get the corresponding advertising revenues, and Facebook does instead.
Isn't this the same problem of people glancing at the front page of a paper and not buying it? Yet apparently newspaper companies put that clear plastic in there so that the front page could be read, the assumption being that seeing the front page headline is more likely to make you buy the paper than not seeing it.
So too, the point of "clickbait" is that they are doing everything in their power to make you click. So the assumption that there is a much larger audience that would click if only they didn't have access to the link from Facebook is, well, difficult to believe.
The issue with this law is that there only opt out is the one that Facebook have taken. If they allow links to any news providers, then they must allow links to all news providers, and pay for them. And if they cannot reach a fair agreement, the arbitration is compulsory - ignore the value Facebook gives to News Corp, consider the value News Corp gives to Facebook.
It's possible to come up with decent regulation/law that does what this one is nominally advertised as doing. But this one is unreasonable.
(Also, the way we got to this point is worth considering. Murdoch spent a decade kicking out prime ministers and destroying democratic oversight. Once he'd finally abolished any expectation that democracy serves the people, he wrote a law and gave it to the parliament to move wealth from his successful advertising companies to his own less successful advertising companies.)
HN links to articles in 99% of its posts. If HN had to pay a link tax, would it survive?
I hate FB too, and avoid their products, but Australia's new law is Mafia style extortion, and we need to separate our feelings about FB when judging this law.
Japanese did their fair share of disgusting things during WWII and occupation of China, Korea, but the article sounds like and old joke about a mugger who says he saved a girl today. He didn't mug her, so that counts as a save.
Still in MVP mode - but it already made some sales.
What's different about it from similar solutions is the way you can get data from an Excel file (most other companies have the JSON and CSV figured out).
It supports Excel style addressing so it's pretty flexible on how you reach for the data inside a PowerPoint template (access every sheet, every cell, named range or table to use it in merging process).
People use it for various kinds of use-cases - creating certificates, automating pricing offers, delivering employee feedback forms, preparing market research presentations and even subtitles for a theatrical play.