I've worked in engineering management for over 20 years and neither I nor any of my peers have ever been happy with the state of regression testing for our products. Creating the tests slows down the team's development velocity and the tests are always breaking. Kwistr is designed to solve this.
Unlike most current tools, Kwistr doesn't try to do functional and regression testing at the same time. In fact, it doesn't try to do functional testing at all. It only does regression testing. By focusing on only regression testing, it is able to automate a significant portion of the regression test creation. In many cases, Kwistr is able to provide 100% regression test coverage without the need to create a single regression test case manually.
Teller, Penn & Teller once said:
"Sometimes magic is just someone spending more time on something than anyone else might reasonably expect."
The same could be said of both startups and software.
Getting software to the point where your audience can immediately connect with it takes a lot more time than one would expect. Startups, like software, require tremendous effort -- much of of is invisible to average person. Like magicians, it takes founders and product developers many years of slogging it out, worrying about every little detail, to make the final product look effortless.
When designing your applications, always make sure you capture the context and the user's intent - capture why they are entering particular data or performing a particular action. Without the metadata to capture the context and intent, the raw data will be much less valuable.
I recently started training again. I was a competitive swimmer for most of my early life, but haven't seriously trained since then. Being the true geek that I am, I wasn't about to do embark on this new journey without the proper apps.
For running, there's Runkeeper. For swimming, there's Swim.com. For weight training, there's ... no idea. There are too many horrid apps to weed through.
What I want, and haven't found yet, is the ability to merge all of the data together into a single place. This should be a solved problem by now. It seems as if consolidating workout data can be done with a few key integrations. Why hasn't it been done before?
While some of these apps have (incomplete) APIs and offer (limited and delayed) data exports, not all of them do. When you do get the data, it is nearly useless.
The app's data is useless because it doesn't include context - it doesn't include the user's intent. The app knows the intent of the behavior represented in the data. The app knows what the data means. Runkeeper knows that this morning's run was workout 6 of 20 in a 5k training plan and not actually me being chased by a bear. Swim.com knows that GPS is useless for swimming and measuring swimming distances in miles is silly.
Underneath the hood, most apps store the same raw data. It's the metadata around that data that makes the data valuable. The raw data itself is a commodity.
Rob's Pike's presentation at the SPLASH ACM conference includes a few great insights into maintaining large software projects.
Go was created to solve real and immediate problems at scale. It is not a research language.
Go was not built to test theories or implement research ideas. It was developed in reaction to specific problems identified in the C++ and Java development Pike saw at Google.
Code generation and languages that rely on formatting for syntax (python) don't mix well.
Python's whitespace syntax has always seemed fragile to me. The difficulty faced at Google's scale must be immense. Rather than a fault of the language, this seems more of a tools deficiency. If python had a tool like gofmt that worked at the lexer/parser level, this would likely not be an issue.
C like languages are approachable by the largest number of current and future developers.
Lisp, Erlang, and other non-C-like languages may be expressive, but at the expense of approachability. Go's familiar syntax allows it to be approachable by the largest number of developers.
"Exponentially smaller means exponentially faster."
Nothing more than optimization 101 - do less to be done sooner. The presentation gives some great comparisons between C++ and Go compile times that highlight Go's superior approach to handling #includes.
"Dependency hygiene trumps code reuse."
At some point, updating object oriented software projects that use a lot of inheritance becomes a game of Jenga. The risk of changing decisions made at the start of the project becomes increasingly difficult to mitigate as they are now buried under years of accumulated code.
The lack of default function arguments helps with API clarity.
I agree with this in theory, but this is too easy to circumvent. I wonder if it would have been better to officially support this rather than force those that really want to do this to roll their own potentially inconsistent solution.
Adding exported names to packages cannot break code that uses that package.
To properly evolve and maintain any codebase, you have to be able to make changes at all levels of the codebase in a predictable manner. Go takes this very seriously.
Errors are normal, not exceptional. Think about them and deal with them when they arise.
In my experience, most developers simply to not have enough experience writing "system" code that has to work 100% correctly despite the seemingly pathological behavior of other applications, networks, and hardware. Once you have this experience, the error becomes the expected expected return value and the focus of the code. It makes sense for Go to force the issue considering its focus as a "systems" language.
Coding conventions enforced via tools - effective due to built in lexer/parser in the std library. Use gofix modules to update existing code to align with changes in APIs.
Gofmt and gofix are simply amazing. The recognition that core libraries might need to change, and the foresight to include the ability to automatically address these changes into the core itself will go a long way towards ensuring Go succeeds. I can think of many examples on my own projects where I could have used gofix to make painful refactoring faster and safer. Every language should have these tools.