Tag Info

Hot answers tagged

185

You have stumbled on the achilles heel of most CS educations: they teach you the tools and techniques, but not the trade. Building software is a craft, one which you only acquire through years of practice and the experience of having your software used (users are much harsher critics than teachers). Building software is also quite often a business, one where ...


131

You are really talking about technical debt. Maybe a metaphor would help your managers. I often compare the effect of technical debt in software to cooking in a dirty kitchen. If the sink and counters and stove are piled with dirty dishes and there is trash on the floor, it takes longer to make a meal. However, the fastest way to prepare the very next ...


101

When I met with my boss to discuss this, he said I should include refactoring in all my estimates. He said it's not a problem he wants to think about. Instead, I should handle it. This isn't a problem that management in general wants to think about. They aren't the engineers, you are. Just make this an unspoken part of all of your estimates, and you'll ...


87

Sounds like every second system that has been thrown at me to fix. Relax, this happens to a lot of people. A junior thrown in at the deep end with no experience, who has no help, no support and no guidance isn't exactly a recipe for success. Hiring and expecting a junior programmer to build a brand new system from scratch that works well, performs well and ...


54

This depends ENTIRELY on the type of work that you're doing. For a lot of situations Test-Driven-Development, like you're currently doing, is definitely the way to go. Overall you'll spend less time on the project since you're not having to constantly go back and fix bugs and edge cases that you didn't account for the first time around. With the first ...


53

In my experience, the answer is sadly no. I've lost many jobs due to my wanting to push a culture of craftsmanship over sloppy hacks, design patterns over procedural code written as object-oriented, and embracing new technology over staying with obsolete legacy tech. Note that I don't regret those choices, but the reality is that very few of our developer ...


50

Here are some numbers to think about: In 2000, research found that up to 90% of the total cost of software systems was spent on maintenance and evolution. Overall, research has found that at least 50% of the cost of a software system is in maintenance. In the US alone, annual maintenance costs are approaching $70 billion. By spending the time to follow ...


46

Whenever you start from scratch again, you'll almost certainly make the same amount of mistakes (or more because the Second System Syndromme tends to kick in). They will be different mistakes, but there will be similar amount of time to spend with debugging and similar despair about how it's not a good fit. It will also delay deployment into production (or ...


43

You've stumbled across something that plagues programmers everywhere at some point in their careers: this code needs to be refactored, there are architectural issues over there, this module is becoming unmaintainable, etc. Because of the present culture of your organization, however, you're being pushed to focus on work that only yields directly visible ...


34

From my experiences I would say as having been a long time contractor myself, 20+ years, generally when you are a contractor, you aren't there to affect change, you are there to be a warm body filling a seat and doing what you are told, unless your manager mandates something different specifically. Don't get invested If they don't see the huge mistake ...


34

You don't. I see this question and all questions like it as a bit of a dead end. You can't "convince" people of anything. If they aren't already aware of things like this or investigating it, chances are they don't give a flip. And no amount of data will convince them otherwise. Change must come from within. You can lead a horse to water but you can't make ...


32

The second way is better, in my opinion. It feels slower but the amount of re-work and fixing and retesting will be a lot less and will ultimately lead to a better product. You say it takes "weeks" to write a program - but you already know that if you go with the first method, you can write the program in "days" and then spend "weeks" in the "correct all ...


30

You refer to Technical Debt. We all accrue technical debt in the products we develop over time, refactoring is one of the very common and effective ways of reducing this technical debt, though many companies never pay down their technical debt. These companies tend to find their software extremely unstable years down the road, and the technical debt becomes ...


29

It's like Gandhi said when asked if his tactic would work with someone like Hitler. He said, "It would be difficult." But I think there's a fair argument that the answer really is "No." Sadly, I don't think what you are trying to do can be done. It's not that I'm trying to be pessimistic, but rather I'm trying to be honest. The problem to me is not that ...


26

There's hope, but it's an uphill battle, especially if nobody realizes the database design is horrible. You can try to abstract the nastiness away with abstraction layers, but chances are it won't be worth the battle. My advice would be to create enough abstractions over the database that the application itself is clean and properly designed; that way if ...


25

I've answered a similar question here before so this might be considered a duplicate. Basically, you're not going to get signoff to do a "refactoring effort". The way you make the code cleaner is to follow the boy scout rule: always leave code cleaner when you leave it than when you arrived. Just like paying down real debt can seem like an insurmountable ...


24

Technical debt is just an abstract idea that, somewhere along the lines of designing, building, testing, and maintaining a system, certain decisions were made such that the product has become more difficult to test and maintain. Having more technical debt means that it will become more difficult to continue to develop a system - you either need to cope with ...


23

First thing to do is change the wording. Calling it "technical debt" gives management the idea that allowing it is an investment of some sort — when really it's more like a virus. (I'm like the Dave Ramsey of technical debt.) Allowing it to go unpaid comes with a huge cost which can't be seen or easily quantified. List problems such as the following ...


22

I think the answer here is fairly simple - the key feature of technical debt is that its something we incur by choice. We choose to make architectural, design or implementation decisions that we expect will cause us issues later in order to achieve specific objectives sooner. A bug is not something we choose to have in our code - so de-facto its not ...


21

I can give you one example from my experience. About 10 or 12 years ago I inherited an application from a team of developers that ended up leaving the company (too long to get into here...). The system was a large home-grown middleware report generation system. It ran every week night and generated about 2 dozen Excel reports for senior executives of a ...


21

Every time you notice something like that, enter a new ticket into your issue tracking system. Make a habit to use issue tracker as a primary tool to communicate stuff like that, because from there, it will be easy to pick, evaluate and prioritize for your senior colleagues / lead / manager / whoever is responsible for tracking the issues in your project. ...


21

I forget where I first read it, but I just wanted to echo, somewhat more forcefully, what other people have said: Shipping is a feature. There is nothing worse than that one guy who keeps "cleaning up" existing (possibly hacky, ugly, dirty) code that works perfectly well, introducing new bugs, etc. What matters in the real world is getting your job ...


20

Interestingly, all the "rockstar" programmers I ever worked with were extremely humble, keen to learn, and ready to admit that they don't know everything. Heck, many were actually outright self-deprecating, at least in light-hearted moments. I don't think I've ever met a developer who thinks their coding "can't be improved", but something tells me these ...


20

Every project leaves you smarter than you were before. After every project you will have accumulated more experience which would have been very handy when you had it from the start. I know that it is hard to not revisit everything and apply what you have learned. But remember: Perfect is the enemy of good. For the client it is always better to have a good ...


19

Your description fits Foote and Yoder's Big Ball of Mud: Over the last several years, a number of authors... have presented patterns that characterize high-level software architectures... In an ideal world, every system would be an exemplar of one or more such high-level patterns. Yet, this is not so. The architecture that actually predominates in ...


18

Yes. Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. Source: Wikipedia Read technical debt as something you could have avoided by having a better workflow (for example doing architecture ...


16

The only way to go fast is to go well. I saw "Uncle" Bob Martin speak on this at a conference once. Luckily, a quote of it is on line. There's no such thing as quick and dirty in software. Dirty means slow. Dirty means death. Bad code slows everyone down. You've felt it. I've felt it. We've all been slowed down by bad code. We've all been slowed ...


16

My manager has tight deadlines to meet. Most do. The current project I am working on is currently on schedule Good. Keep it that way! I've noticed a couple of quite significant areas in the code that are really badly written. (Bits of code get called two or three times, when they only need to be called once.) If that's not a major ...


15

Here is a choice my team had once. The company I worked for turned over 10million/annum. The division I joined was loosing 500K/Month, the business was financed by a security on the bosses house. Choice 1. Best practice. The whole lot..... would have bankrupted the owner. Choice 2. Major trade show in 10 weeks. 8 developers, war mode. No design, no ...



Only top voted, non community-wiki answers of a minimum length are eligible