Tag Info

Hot answers tagged

226

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 ...


139

Sorry to say this You aren't going to want to hear this, but he is not completely wrong. If you are doing work for hire for external companies as a consultant, and they are willing to accept the most slapped together thing you can do and don't complain, and are willing to come back over and over again for you to do more work, your boss is 100% correct. ...


138

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 ...


129

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 ...


104

This sounds like every other 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 ...


82

Sounds Like My Old Job (1 Sales Person, 1 Graphics Person, 2 Programmers) This used to happen all the time at my old job. I agree that sales drives everything. The shop manager (Skill Set: 80% Sales 20% Graphics) was constantly underselling features customers wanted. A 20 hour job would be sold at a 10 hour price because the customer wasn't willing to pay ...


65

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 ...


57

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 ...


57

Whenever you start from scratch, you'll almost certainly make the same amount of mistakes or more due to the Second System Syndromme. Your new mistakes will be different, but the amount of time needed for debugging will be similar and so will despair about how it's not a good fit. It will also delay deployment into production or deployment of new features if ...


55

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 ...


47

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 ...


46

I have seen companies do this. They end up with angry customers. Customers have a habit to come back and ask for new features as soon as the app starts to make money for them or is integrated in their business flow. You will soon have to tell those customers that you can't add new features to the mess you created, because you can't handle the code base ...


40

It will earn the company F million pounds, over t years at a cost of x dev-days work Which is ignoring maintenance costs, support costs, the cost of sales/marketing, and makes a whole lot of assumptions about how the feature will be taken in the marketplace. But whatever; your question is clear enough about what you're looking for: How can I make a ...


38

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 ...


36

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 ...


35

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 ...


35

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 ...


33

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

Two choices really: Quit, or grow a backbone. I think I don't have to explain much about quitting.. that one is obvious. If you can neither take it nor dare to change it, it's the only way to go forward. If you do want to change this, then it is your responsibility to stand up against this. This does need "a backbone", because you will be going against ...


28

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 ...


28

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 ...


27

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 ...


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 ...


26

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 ...


26

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 ...


25

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 ...


24

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 ...


23

I believe there's two factors you should consider that you at least didn't cover in your Q. Let me define these as I use them, then I'll get onto the business of answering your Q. Risk Opportunity cost Risk is probably obvious: The chance that they pile a mountain of money into something that goes nowhere. Risk is compounded by what Brooks called "Second ...


23

Teach him about technical debt What you have to do is to make him realize the consequences of the choices that he makes. Quick and dirty can be alright sometimes because you can get things done quicker, but it does have long term consequences. If for example the project was never intended to have a large code base, quick and dirty might be the perfectly ...



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