Myself I've been thinking about the same thing as the STEPS paper aims at lately, and haven't had any time to pursue it either. I'll do it in a few years from now though. Worth noting is that once you move over to the world of writing 100, 1000, or 10 000 times less code, there will be no turning back. Nobody will want to write Java with that baggage, no matter what the salaries are. Myself, I would consider replacing the outskirts and glue with something like OMeta, if I find it suitable. If it is, I bet other game developers would be enthralled by the thought of developing a game in a few k lines of code. But this is, as I said, not an option until three years or more ahead. Until then I'll be too busy building a source of income in game development for myself.
For me, starting my own business is both what I want to get rid of and what I want more of. I want more broad problems in diverse disciplines which I can solve when I feel like it, and games in general has always had a strong appeal to me. What I want to get rid of, on the other hand, is mediocracy. In smaller companies I've had the fortune of working mostly with good people, or people who knew when to listen to others. But I'll let you be the judge of competence based on some events in a project at a large company I've worked at:
- Architect 1 says (and sticks to): "Fewer lines is is not better code!" He claims that four short LoC are better than one short LoC, as the four rows "are built in" [to Java's standard library], not made by someone on the team. Hell, why not just make all code a big lump of standard library calls?
- We ran a lousy code quality measuring tool, which sets score on things in the code. For instance it claimed that leaving a class or method undocumented was no good, so Architect 2 fills the code with empty (!) comments.
- The code quality measure tools has a few flaws, for instance it thinks this built-in Java snippet
enum DocumentButton { SAVE { public String getName() { return "Save Document"; } }, LOAD { public String getName() { return "Load Document"; } }; }is more complex than this man-made solution:
class DocumentButton { public DocumentButton SAVE = new DocumentButton("Save Document"); public DocumentButton LOAD = new DocumentButton("Load Document"); private static DocumentButton[] btns = new DocumentButton[] {SAVE, LOAD}; private String name; private DocumentButton(String name) { this.name = name; } public String getName() { return name; } public DocumentButton[] values() { return btns; } }and so Architect 2 readily goes about rewriting some 40-50 classes. Also Architect 1 thinks this is a lot less complex, and thinks that the work performed by Architect 2 is good. (I personally guess that since the first alternative is a new syntax since Java 6, which came out more than seven years ago, Architect 1 hasn't had time to adopt properly.) I definitely agree that the first syntax is ugly, but that inherent in the nature of Java. Surely there must be better things to do in a project that has been postponed several times already? - Some three-four months ago I brought up in a meeting (yeah, there's plenty of those too) with Architect 1 that I'd identified a feature-duplication between two parts of the systems. They were both sort of views of the other system, i.e. highly coupled with low cohesion, and needed to converge. The same thing I told Architect 2 one-two months ago, and warned him as he was headed into that domain, but he chose to continue his path towards a messy and. Sure enough, suddenly Architect 2 caved in a week ago, because he was not managing to implement code without a bigger refactoring.
- But worse, far worse than these and plenty of other events, is the inability of both architects to "see a system in your head"; to get a mental picture of flow, objects, data and what is important, which parts may constitute pitfalls and so forth. The customer is getting frustrated at this point, but they have no clue as to what is wrong. Neither is the rest of the team I think, but I've never worked with a team of such low development pace before in my now 13 year long professional career.
- Even though the architects are the biggest problem, no one in the team seems to know the basics of how to use a call stack or how to use breakpoints to find out how program flows. Sure, they set breakpoints, but it all seems irrational to me, and sure enough, it usually takes hours to find the root cause of a simple, repeatable crash or similar problem.
- Usability is of poor quality; with flow, layout, user friendliness, use of commonly-understood widgets/features, understanding of domain problems and overall design being only slightly better than the average HTML page of 1995.
- There have been junior developers too, all quit now though. They didn't have any quality awareness, which is just how some people are. If you're open about it and don't expect others to right your wrongs, I think it's mostly fine if the customer thinks so. She didn't, which is fine too. It's a craft, and building from scratch with little schooling and no sense of quality will get you nothing worthwhile.
- System is not DRY, in some instances up to seven changes need to be performed to get correct, expected results. A thing called search-and-replace, or merely "search", which would do the job if used, isn't.
There's plenty more, but in short: I'm really tired of mediocracy, ugliness, low quality and low pace after one whole year in this project. I seriously can't stand it any more, despite the damn good pay. My contract runs out in May, and I'll happily walk out of there knowing my mental health will improve. What I enjoyed when I first came here (apart from the pay) was the absence of stress. That is a nice feeling, but too far off on that spectrum and you'll get a bad itch too. I won't like whatever pay I get after this as much, but that's where my indie game development comes in. One day (and after that - OMeta)!
