Most AI adoption advice optimises the existing process. Tickets, standups, code review, documentation — these didn't emerge from first principles. They evolved as workarounds for human limitations: forgetting, context loss, blind spots, communication bandwidth. AI doesn't share most of those constraints. Embedding it into workflows designed around human limitations means asking it to operate inside constraints built for a problem it doesn't have. The argument here is that the failure mode isn't tooling or team readiness — it's that the process itself was always the bottleneck.
We started with a single developer and an artist. And two weeks ago a GUI developer joined the team. The team has been working full time on this.
How we did it? Well, we came up with a few leap of faith questions, like : "Nowadays most football games are too complicated to play and if we build what feels like arcade, people would enjoy playing it" and we started building minimum thing which we can test if we were right or not. This is where we are by the end of the 5th week :)
We have been doing agile development with a separate product management team writing down user stories for us. But the issue of defining "completeness" has been created a lot of frictions. While considering the development approach for our new spin off game studio, we came across LEAN approach and we are really proud of how much we could put in there within 5 weeks and we feel like most of that effort has been put as in "working code".
LEAN approach not only helped us with the amount of visibility on the product we are working on, but also re-shaped the way we think about "completeness" of a feature. Result of the experiment: happier team, more code in production, 2 or 3 builds a day.
Strongly suggested for small teams, who have less to waste. That's what I wish to share with friends working in startups around the globe.
CLI is great from *NIX perspective and I believe most of us had used it extensively in the past. I still use CLI but if and only if it suits as the best tool for the problem I'm working on. The fact is, that the paradigm has changed, therefore the way we interact with our computing devices.
IMHO, bigotry is not only bad in politics. We have to embrace the change, learn new tools, improve, share our knowledge and not only make our jobs better for ourselves, but also for others. Especially for rookies, who will have to be doing more tomorrow than what we do today. I don't believe `libcaca` has anything to serve this purpose.
Using mutt instead of gmail; I'd ask "Why?". We don't need to stick with the tools we've used 10 years ago. If I'd be looking for a challenge as a sysadmin, I'd learn ways to better utilize cloud environments, look for better ways to serve static content for large volume systems, improve my tool base for managing geographically distributed servers, learn about the requirements of the new era of real time web, how to deploy node.js on my servers, etc.
IMHO, there're two points here;
1. Unit testing is not TDD
2. TDD has nothing to do with software testing
TDD is good for developing rapid changing codebases with short development cycles with known requirements and a harsh time pressure, but it's a front loaded way as well.
By which I mean, you have to invest some hours beforehand to make sure you're not shipping crap because you didn't have time to see what would break or to make sure you didn't skipped the controller your GUI developer needed.
TDD tries to ensure one thing only: "Awareness". You accept the initial costs of TDD if awareness is a big issue for you. Otherwise, use something else which serves you to solve it.
If you're aware of what you will be implementing and if there's a mechanism you can check your code against, it'd be efficient, right? TDD uses unit tests for documenting that "Awareness", aiming to utilize the benefits of unit testing as well.
You're right, that it is not feasible trying to test every aspect of your solution via unit tests and that's why there are integration tests, systems tests and acceptance tests. So if you're planning to find defects via the unit tests you're writing for your TDD cycle, think again. Unit tests are good for checking "completeness" and a great tool helping with regressions. Nothing more and nothing less.
As a good engineering practice, we adopt the method of working, based on how we planned to work. If we find TDD fruitful to implement, we avoid putting any logic to controllers. We implement our business logic behind the controller, which also cleans it off of implementation specific crap. Besides us using a completely detached GUI layer helps us write controller unit tests running via HTTP.
We simplified our working environment and make it suitable for TDD, by ways we found to provide more capabilities to us. If we're not to use TDD, we employ other logics and structures, which would fit well with the method we'd use instead.
Long story short, TDD gives what TDD is intended for and as long as you cooperate. If you expect more than it can provide, you'd be disappointed. Regardless of your development method, you have to make sure your development/architecture models and your tool set complies with your method of choice. The rest relies in the question "What do you need your development model to solve for you?"