Jump to content
  • Advertisement

Aceticon

Member
  • Content Count

    25
  • Joined

  • Last visited

  • Days Won

    1

Aceticon last won the day on September 24 2018

Aceticon had the most liked content!

Community Reputation

32 Neutral

About Aceticon

  • Rank
    Member

Personal Information

  • Interests
    Business
    Design
    DevOps
    Programming

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The thing to aim for isn't to completely throw away and rewrite from scratch, as in the example i posted, but to treat development like painting the forth rail bridge. It should be rewritten a subsection at a time by careful refactoring, with each refactor considered and ensuring that each component is properly isolated and uses proper object oriented design. I've worked as a contractor for almost 2 decades in a couple of industries with maybe 15-20 different companies and have seen both situations were a complete rewrite was the chosen solution and others were continuous refactoring was it. I've also been brought in far too many times as the external (expensive) senior guy to fix the mess the software has turned into. It really depends of the situation: continuous refactoring is the best option in my opinion if done from early one and with few interruptions, though it requires at one or two people who know what they're doing rather than just the typical mid-level coders. However, once a couple of significant requirement changes come trough and are hacked into a code base and/or a couple of people were responsible for the software, each thinking they know best and doing code their way mismatched from the ways already used in the code, the technical debt becomes so large that any additional requirement takes ages to implement. When that happens, that software has often reached a point were a full rewrite is a more viable solution than trying to live with it for the meanwhile whilst trying to refactor it into something maintainable. This is much more so if the software is frequently updated with new requirements. My gut feeling is that where the balance lies depends on the business environment where that software is used is one generating frequent requirement changes or not - in environments where there is a near constant stream of new requirements it's pretty much impossible to do any refactoring of large important blocks, since any urgent new requirements that come are likely to impact that code and have time-constrainsts which are incompatible with the refactoring (as you can't really refactor and make new code at the same time in the same code area). That said, maybe half the full rewrites I worked in or seen done turned out to be very messy affairs all around, mostly because good Business Analysts and Technical Analysts are as rare as hen's teeth so the software that ended up made didn't actually implemented the same user requirements as the old software.
  2. It was my personal experience, whilst going through a similar learning process myself in similar conditions (at about the same time, though luckily I jumped into Java and discovered the Design Patterns book early), that there is a stage when one has learned some Software Design and starts overengineering everything, resulting in such as heavy mass of things that "seem like a good idea" and "just in case it's needed" that it effectively defeats the purpose of the whole OO philosophy. Eventually one starts doing things the KISS way, Refactoring code when the conditions that defined a design decision change, and designing software driven by a "what does this choice delivers and what does it cost now and later" thus producing much more maintainable deliverable functionality (what code delivers matters vastly more than The Code) and faster. Looking back, I would say this transition only properly happened to me about 10 years after I started working as a Software Developer. I reckon this is the point when one transits from Junior Software Designer to Experienced Software Designer. It takes time to get there and I suspect not that many make this transition. There is a similar thing around Software Development Processes, which can be observed in, for example, how so many groups use things like Agile in a recipe-like fashion (and often ditching the most important non-programming bits) rather than elements of it selected based on the tradeoffs of what they deliver to the process versus what they cost (not just money cost, but also things like time, bug rates, flexibility, learning rates, etc) in the context of a specific environment (i.e. the subset of Agile for use in a big non-IT corporation is not at all the same as that for use in an Indie Game House). PS. I think the bit you mentioned about the ignorant spreading their ignorance (and damn, I look at online tutorials and that shit is all over) is basically Dunning-Krugger in action, just like we see all over society and the Internet at the moment: people who have learned just enough to think they know a lot but not yet enough to understand just how much, much more they need to learn, are still very low in terms of knowledge in an area but at the peak of their self-confidence in terms of what they think they know, so they spread their ignorance around as if it's Wisdom, and do so with all the confidence of the trully ignorant. The Original Post in this article is a stunning example of just that, which is probably why all the Old-Seadog Programmers around here seem to have jumped on it.
  3. Whilst I have not worked in this style, I have designed systems architectures which made heavy use of segregating things into separate services (mostly to facilitate redundancy and scalability) and in my experience there is a significant cost associated with defining proper communications interfaces between services (aka APIs) and - maybe more importantly - changing them when changes of requirements result in changes to multiple "services". In fact, the part of the secret in designing high performance distributed systems was to find a good balance between decoupling and performance (both program performance and software development process performance) and always be aware of fake decoupling (i.e. when things look like decoupled, but they only work as long as certain assumptions - such as, say, no more than X elements are sent - are the same inside the code on all sides). The whole thing as you described it sounds as OO encapsulation but wrapped with a heavy layer that adds quite a lot of performance overhead and a whole new class of problems around things such as failure of request execution and API version mismatch (or even worse problems, if people decide to use networking between "services"), all the while seemingly not delivering anything of value (catering to programmer fashionism and prima-donna behaviours is not value, IMHO). Both in the literature and my experience, the best level to have service APIs at is as self-contained consistent business operations (i.e. ops which must be wholly executed or not executed at all), and I can only imagine how "interesting" things start getting with such high levels of service granularity as you seem to decribe when dealing with things such as Database Transactions.
  4. I started learning OO development ages ago from a Pascal and C background, still in Uni, because I felt my code was disorganized and hard to maintain and there must be a better way to do it. I was but a hobbyist back then, doing small projects (tiny even, if compared to many of the things I did later), but there was already enough frustration that I felt compelled to learn a different style of programming. Even for a one-person hobbyist it's still worth it because it really cuts down on complexity of the whole code allowing a single person to tackle far more complex projects and significantly reduces the things a coder needs to remember (or look up later if forgotten) thus reducing forgetfulness bugs as well as time wasted having to rediscover, from the code, shit one did some months before. I strongly recommend you get the original "Design Patterns" book from the gang of four (not the most recent fashion-following me-too patterns books) and read the first 70 pages (you can ignore the actual patterns if you want). It is quite the intro to the Object Oriented Design Principles and, already 20 years ago, it addressed things like balancing the use of polymorphism with that of delegation.
  5. I've worked about 14 years as a freelancer (contractor) Software Developer in a couple of Industries and far too often I was called in to fix code bases which had grown to be near unmaintainable. Maybe the single biggest nastiest problem I used to find (possibly the most frequent also) was when the work of 3 or 4 "coding artists" over a couple of years had pilled up into a bug-ridden unmaintainable mess of mismatched coding techniques and software design approaches. It didn't really matter if the one, two or even all of those developers was trully gifted - once the next one started doing their "art" their own way on top of a different style (and then the next and the next and the next) the thing quickly became unreadable due to different naming conventions, full of weird bugs due to mismatched assumptions (say, things like one person returning NULL arrays as meaning NOT_FOUND but another doing it by returning zero-size arrays) and vastly harder to grasp and mantain due to the huge number of traps when trying make use of code from different authors with different rules. We're not Artists, at best we're a mix of Craftsman and Engineer - yes, there's room for flair, as long as one still considers the people one works with, those who will pick up our code later or even ourselves in 6 months or 1 years' time when we pick up our own code and go "Oh, shit, I forgot how I did this!". Unsurprisingly it has been my experience that as soon one moves beyond little projects and into anything major, a team of average but trully cooperating developers will outdeliver a team of prima-donnas every day or the week in productivity and quality. (And I say this as having been one such "artist" and "prima-donna" earlier in my career)
  6. It is genuinely interesting that people who don't know how to use OO for the reasons OO exists (reduce the likelyhood of bugs, reduce the amount of information that must be communicated between developers and control complexity by reducing cross-dependencies so that very large projects can be done efficiently, to pick just a few examples) put up their own deeply flawed pseudo-OO strawman as an example "OO" and then proceed to argue that their imaginary construct shows how shit OO is and why people should stop doing it. Even more funny is that this is basically a back-to-spaghetti-code movement that reverses what happened 25 years ago, when people figured out that making everything have access to everything and be able to change everything was spectacularly bad from the point of view of making code that has few bugs and can be maintained and extended. It seems to be a sadly common thing in the Game Development branch of IT that people who have very little knowledge of how to architect large scale solutions and how to make effective and efficient software development processes, like to, from their peak certainty (and ignorance) spot in the Dunning-Krugger curve, opinionate about software architecture concerns without even a mention of things like development process efficiency in aggregate (not just coding speed, something which is the least important part of it), inter and intra-team dependencies, flexibility for maintenability and extendability, bug reduction and bug discovery and removal efficiency. Maybe it's something to do with so many developers in the Industry not having to maintain their own code (game shipped = crap code and design problems solved) and being in average more junior than the rest of the industry so less likely to have seen enough projects in enough different situations to have grown beyond being just coders and to awareness of technical design and architectural concerns in the software development process? I'm a little sad and a little angry that people who have not demonstrated much in the way of wisdom in terms of software development processes, are trying to undo decades of hard learned lessons without even understand why those things are there, a bit like saying "I never had a car accident and don't like wearing a seatbelt, so I want to convince everybody else not to wear seatbelts".
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!