Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There's no shame in code that is simply "good enough"

blog.phiz.net

Post reply on HN
Print view View original

51–60 of 68 posts

Re: There's no shame in code that is simply "good enough"

#51

Post by brazzy »

rosariom wrote: post #40

This is the experienced developers dilemma: "To engineer or to not engineer"; engineering usually turning out to be over engineering. A more experienced developer friend of mine would always tell me: "build for today's requirements". I try hard to fight the design/architect voices in my head that always want to imagine this made up future where we will need X or else we cannot go live. These voices usually only stall…

This. A hundred times this. It is truly mind-boggling how many crimes against maintainability are committed in the name of future-proofing.

Re: There's no shame in code that is simply "good enough"

#52

Post by fragsworth »

mgkimsal wrote: post #49
fragsworth wrote: post #47

Earlier quoted context omitted.

I can tell you from first-hand experience, though, that if you cannot scale immediately when the time comes, your business can drastically suffer for it.

I don't disagree, but a few points spring to mind. And in my earlier post, I wasn't really thinking about 'scaling', but new functionality/features. Occasionally "immediately" really does mean "in the next 5 minutes". Oftentimes it actually means more on the order of days or a couple weeks. "Scaling" can mean different things, and anything beyond "scaling" web requests alone will likely mean a shift in business opera…

Yeah. I was only referring to scaling in the sense that the number of users increases. Often, it is easier to implement an application by ignoring scalability, and you can get it out the door quicker.

However, this can be a terrible mistake if your users are not resilient to downtime or lost data (e.g. in the case of Facebook games). Even just a few hours of downtime or slowdown can cause a significant, permanent drop in users.

Re: There's no shame in code that is simply "good enough"

#54

Post by RandallBrown »

I was working on a project with another more senior developer and I remember saying we should refactor some part of the code or design it differently somehow and he said "Why, it already works?"

The only argument I could really come up with involved too many coding buzzwords to be taken seriously and we moved on to the next task.

That's kind of stuck with me. Whenever I'm thinking about a code change or "clever" design I just try and see if there's a justification beyond something involving words like "abstract" or "cohesion".

Re: There's no shame in code that is simply "good enough"

#55

Post by its_so_on »

Natsu wrote: post #50
its_so_on wrote: post #25

Earlier quoted context omitted.

right, but forget fine china: some people would prefer to give their guests real plates, and do so when they have 10 guests, but don't have 100 plates, so when 100 guests show up on their lawn they use disposable plates. The reason doesn't matter. See my comment above about why it's hard to think of code as being a consumable good AT ALL (for any reason). My point wasn't really about tableware, it was about disposabl…

That then points to a reasonable solution: use disposable stuff for rare events but have a good set for everyday use.

i guess i was being incredibly unclear then because that was my whole point. :/

a lot of code is for rare disposable events and doesn't need to be built like a ship; more like a paper airplane.

Re: There's no shame in code that is simply "good enough"

#56

Post by kahuna »

rosariom wrote: post #40

This is the experienced developers dilemma: "To engineer or to not engineer"; engineering usually turning out to be over engineering. A more experienced developer friend of mine would always tell me: "build for today's requirements". I try hard to fight the design/architect voices in my head that always want to imagine this made up future where we will need X or else we cannot go live. These voices usually only stall…

Depends if you are engineering an enterprise system/product, or building a smaller one off project.

In the case of the enterprise solution that will be around for the next 10 years, I would agree with your tech lead.

Every time you make a code change for something that is out of dev budget, you face a budget overrun in the project that was interrupted.

If you choose to deliver something that just works and as soon as possible, your total costs tend to balloon over the lifetime of the system.

Question to ask is: how long would it take for a new dev (someone who has never seen the code) to change the tradeReference naming convention to include the asset type, or some conditional tag, lets say to conform to reporting regulations or even an expanded business mandate?

Interfaces do help here, because the new guy can make a localized change, write a small unit test, and commit the code to source control before you can say "rebuilding search index".

Keep in mind that you do not know if something is well architected until AFTER its been in production for at least a year and had features built into it for another year or two, and has added new members to the team, and has lost a few of the original team members in that time,

I believe that most people who are able to look back and claim that they have delivered at least three large projects (>500k LOC c++ or >200k LOC java) or product releases that meet the above criteria, would agree with your tech lead.

Re: There's no shame in code that is simply "good enough"

#57

Post by drumdance »

breckinloggins wrote: post #11

This actually causes "coder's block" in me when I start a new project. If I have this cool app or site idea, it often never gets off the ground because I spend too much time trying to create some architectural framework that I assume I need. This is REALLY bad for me in Cocoa/Cocoa Touch apps. Objective-C is so verbose and writing classes is so "mechanically cumbersome" (having to write .h and .m files and duplicate…

I try to think in terms of interfaces, but implement quick & dirty.

So, for example, I may imagine that data sources for a page will come from several places: the db, Google maps, an api like Twitter etc. And I will create stub classes to capture this concept, but the methods will just return hard-coded elements. Eventually if the project goes anywhere I can build out the underlying methods as necessary.

I find this helps me feel like I'm doing real engineering but not get too lost in the abstractions.

Re: There's no shame in code that is simply "good enough"

#59

Post by medius »

Trade-off between building quick functionality vs a flexible, maintainable code is a business decision. Engineers at a startup cannot sit down and design a system for months that will work for 10 million users. However, they also cannot patch their code and have it create problems within a month and then having to redesign it again.

Once your product vision is clear, you can try to see as much into the future as you can. You know where your product can/will go based on what problem you are trying to solve. Once you get into "what-if" territory, you know you have ventured too far.

Therefore, I truly believe that engineers should be aware of the business needs and the product roadmap/vision to make such decisions. Engineers can then decide where(and how much) flexibility should be added. Most of the future-proofing is done for scenarios that may not exist out of the imagination of the engineers. They should know what can be possible and what cannot. No system can be designed to handle all scenarios without adding untold complexity.

Re: There's no shame in code that is simply "good enough"

#60

Post by dan00 »

rosariom wrote: post #40

This is the experienced developers dilemma: "To engineer or to not engineer"; engineering usually turning out to be over engineering. A more experienced developer friend of mine would always tell me: "build for today's requirements". I try hard to fight the design/architect voices in my head that always want to imagine this made up future where we will need X or else we cannot go live. These voices usually only stall…

There's a reason why this happens more often in languages like Java. Because of the verbosity of the language, it's just painful to rewrite anything, even if the current solution isn't that much over engineered. So there might be a greater tendency to over engineer at the beginning, just to avoid any rewriting, which at the end isn't possible.

I'm a full time C++ developer, which might be a bit better in this regard than Java, but not that much, and a hobby Haskell programmer, and one of the greatest things about Haskell is it's brevity. It makes rewriting a lot less painful, so you're not avoiding it that much.

Post reply on HN