Have I taken a wrong path in programming by being excessively worried about code elegance and style?

Question

I am in a major stump right now.

I am a BSIT graduate, but I only started actual programming less than a year ago. I observed that I have the following attitude in programming:

• I tend to be more of a purist, scorning unelegant approaches to solving problems using code
• I tend to look at anything in a large scale, planning everything before I start coding, either in simple flowcharts or complex UML charts
• I have a really strong impulse on refactoring my code, even if I miss deadlines or prolong development times
• I am obsessed with good directory structures, file naming conventions, class, method, and variable naming conventions
• I tend to always want to study something new, even, as I said, at the cost of missing deadlines
• I tend to see software development as something to engineer, to architect; that is, seeing how things relate to each other and how blocks of code can interact (I am a huge fan of loose coupling) i.e the OOP thinking
• I tend to combine OOP and procedural coding whenever I see fit
• I want my code to execute fast (thus the elegant approaches and refactoring)

This bothers me because I see my colleagues doing much better the other way around (aside from the fact that they started programming since our first year in college). By the other way around I mean, they fire up coding, gets the job done much faster because they don't have to really look at how clean their codes are or how elegant their algorithms are, they don't bother with OOP however big their projects are, they mostly use web APIs, piece them together and voila! Working code! CLients are happy, they get paid fast, at the expense of a really unmaintainable or hard-to-read code that lacks structure and conventions, or slow executions of certain actions (which the common reasoning against would be that internet connections are much faster these days, hardware is more powerful).

The excuse I often receive is clients don't care about how you write the code, but they do care about how long you deliver it. If it works then all is good.

Now, did my "purist" approach to programming may have been the wrong way to start programming? Should I just dump these purist concepts and just code the hell up because I have seen it: clients don't really care how beautifully coded it is?

Answer 1

I don't think this is a bad way of programming at all. It really depends on the environment of the place where you work. I think your approach is a very good way of programming; it's quite similar to mine.

The important thing to realize is:

• try to not cut corners (you're already doing this)
• realize when it is cost-efficient to cut corners, and once you have done so, make time to refactor and do it right.
• are you working on throw-away or proof-of-concept code or a spike project? That is, something that is not meant to be released? It is alright to cut corners here, but within reason.

I have worked in environments where people have thought it important to simply get the job done. This means sloppy and lazy code which turns out to be a huge maintenance nightmare. I can see how this is an "advantage" in a situation where you don't ever have to go back to your own code and where some poor soul has to maintain it later. But I look at software engineering as you do - something to architect, and something that is a work of art. That is, my code speaks of my ability as a software engineer. Therefore I take the time to make my code elegant.

If you're finding yourself in a situation where your peers are getting ahead of you because of their sloppy coding then I would ask you to try and educate them of better way of doing things. Try to get management and senior architects involved and impress upon them the importance of good software-engineering practices and how it directly relates to more reliable, robust, less buggy, and more maintainable code (especially useful if you are selling a product that you expect to maintain over a long period of time).

If your superiors don't seem to think so and continue to reward the sloppy coding of your peers and if you find yourself being rated poorly because you take the time to do things right, then you should quit immediately and find a better place to work.

In the long run though, you will come out ahead because you actually take the time to understand conventions and best practices. Your peers will be stuck at an amateur level of programming not really knowing what they are doing.

With regard to the statement that "clients don't care about code", this is a ugly truth that we have to live with. However, if you are a dedicated software engineer with attention to detail, you can build up a suite of tools or custom frameworks that make your job easier over time. This means that eventually you can and will catch up to your "hackish" peers because you have the foundation of a solid framework that you can use to quickly architect and build a system for your clients. Your peers will start everything from scratch and re-invent the wheel whereas you will be using your own tried and true code. The initial cost for you is high, but over time you come out ahead.

To sum it up, don't lose heart. There are plenty of places that reward your dedication, perseverance, and attention to detail! Do not succumb to the temptation of doing things the easy way. That is definitely a step backwards.

Answer 2

Ahem... I believe the answer to be:

Yes.

Answer 3

It ultimately comes down to the project complexity. A 2 line perl script that's only going to be ran once doesn't need to be very beautiful. A 10,000+ source file project needs all the beauty it can get. It sounds like the jobs your friends are taking are a relatively small commitment (less than a few months of development, correct me if I'm wrong :). You're current coding style seems to better fit massive platform development as opposed to freelancing type stuff.

Very meticulous coding lets you pay now for gains later. vice-versa for less elegant solutions. If x is the length of time spent of on the project, here's some models (the constants are hypothetical; sorry if I bore the math majors):

time = 1000 + x  //your style
time = 10x       //their style

you may lose out in small projects, but you will win by a landslide in larger ones.

What should you do? Well, if you can't change your coding style, try to get a job in some projects better suited to it (trust me, they really want people with your kind of style). If you can stand to lose a bit of elegance in order to get things done, then you will be more effective in smaller projects. :D

Answer 4

I guess it depends on the work enviroment you plan to go into. If your going to be an independent software developer doing odd jobs on contract then being a purist is going to cost you more time but probably not get you more pay - a typical client just wants the job "done" (not necessarily elegantly etc). If however you are part of a software team working on a large software project that is your employing companies bread and butter then taking the time to nurture that code and keep it clean, fast etc will definitely pay off long term (in contrast to fast and dirty coding that will bring the product to its knees in a matter of years - if not months).

Answer 5

You have to realize that no matter how good you think you are, you will have to make concessions.

Most clients do not care how something is coded on the inside, as long as it works reliably and does what they want. However it does matter to you, because it has a direct effect on the cost of maintenance. But you need to remember that you cannot go to a customer and say "sorry, you can't have your product for another year because i am just not happy with how pretty the code looks and how it is structured". If you do try to do that, you will find that you have a sudden lack of clients as they desert you and go elsewhere to get the job done. You cannot survive without clients - you need to pay the bills somehow.

So, who is going to change - you or the client?

Answer 6

There is definitely a balance to be struck between getting things done, and getting things done correctly. Developing that sense of pragmatism takes time, practise, and experience. There isn't a "correct" solution to this problem, although there are better or worse solutions in a given context.

Answer 7

There's nothing wrong per se with having high standards; in fact, quite the opposite. You're right that your colleagues are going to get paid sooner and get "more done" with a more laissez-faire approach to their coding, but this will (or at least can) come at the expense of their reputation. The check that a client gives you is not the only thing that you get from them, because you're likely going to want to use them for a recommendation in the future. If you deliver a house of cards that works for a few months but falls apart whenever someone tries to maintain it, you're not likely to get the sort of recommendation that you want.

Practical career advice aside, you simply have different standards than you colleagues, and that's OK. It sounds like you enjoy development, so you simply have to learn how to balance your perfectionist tendencies--and many, if not most, good developers have them--with delivering work. Constantly refactoring your code at the expense of a deadline is not a good idea unless the refactoring is truly necessary, in which case you're probably doing something wrong.

Addressing your issues point-by-point:

1. Being a purist is fine, but being a jerk about it isn't; don't "scorn" inelegant approaches, know when it's appropriate to offer help in correcting them or just learn not to do them yourself
2. There's nothing wrong with high-level planning, but it's frequently going to be wrong, so take that for what it's worth.
3. As I said before, don't refactor simply for the sake of refactoring: have a reason for doing it, and make a case-by-case decision as to whether the reason is worth the cost.
4. This is very common, and (like the first item) just fine as long as you aren't a jerk to others about it
5. Also very common, and A Good Thing, just don't let your ambition and curiosity cause you to fail at your job.
6. Not sure what this has to do with anything (in terms of being a possible negative). Nothing wrong with this unless, again, you're a jerk about it.
7. Even less sure what this has to do with anything
8. I think you're getting the idea

Answer 8

There's a middle path between the extremes of perfectionism and sloppiness. Just practice more and you will find it.

Answer 9

You are on the right path. If you have a knack for design and careful organization, speed and efficiency will develop with time and experience. On the other hand, if you were to turn out each project with the quickest, dirtiest hack available, you would never learn design.

You've only been programming a year? I would say don't sweat too much. Spend some time applying those analytical, organization skills to thinking about how to be more efficient. In another year you will be both faster and produce better code than those who take the other approach.

Answer 10

Have I taken a wrong path in programming by being excessively worried about code elegance and style?

No. But some of the other bullet points in your question are hurting you.

I have two pieces of advice:

• Pick one of your bullets, and for two weeks, ease up on it. Keep a diary and observe what happens. Treat it as a science experiment. Then try another. Eventually you will have an informed idea of what to obsess about. (This procedure is a baby version of Watts Humphrey's Personal Software Process.)

• Remember that shipping is also a feature.

Answer 11

You could also think about moving into projects where the client will care about what your code looks like and how it is structured. Think industrial safety-critical systems, airborne software, etc. - anywhere where your code will be audited.

Answer 12

The thing that's in common between a good engineer and a good scientist is they are always skeptical. I find that at times I have to question what I'm doing, and revalidate it. That includes obsessing about the structure and coherency of APIs, the depth and breath of the design cycle, and occasionally even the theory of gravity just to make sure I'm not off track.

I spent the first quarter of my career with the get shit done approach. Unlike your friends who sound as though they are blessed with the ignorance of being contractors, I had to maintain much of the work I generated during this part of my career. In most cases, that meant wake up in the middle of the night when it broke because it couldn't handle the traffic, or rewrite it when the billing procedure took so long it wouldn't finish in a 24 hour period. Over that time, I learned that I a well thought out solution is actually cheaper than the alternative. Don't worry about your friends, their work will eventually catch up with them.

I would suggest you continue to question this track, and continue down it, simultaneously. The depth of the design process should be a fluid thing. The amount of time you spend deciding how to write your code, versus the amount of time you spend actually writing it, versus the amount of time you spend debugging it are all variables you should be tuning over time. Cut back processes when they seem to slow you down from their weight, and increase them to cover bases when problems occur. This is the nature of processes, both personal and in business. There is no scientific answer for the "right" amount of process of any given type, because the right amount of processes is clearly defined only as being sufficient to prevent the bloating of costs, without creating excessive costs.

In addition to the aforementioned reasons to continue doing more-or-less what you are currently doing, never forget that a lot of people have a tendency to remember names. And as a person who is authoring large numbers of documents (either in the form of machine instructions, or otherwise) developers have a permanent sort of accountability and reputation they often overlook. Most software lives well beyond it's expiration date. Maintainers will be seeing your name associated with those works for years to come. If you do not leave a respectable work, it's only a matter of time before this impacts your career in some way. Project schedules are important, but rarely will anyone be looking at last years project schedules to see which ones were overrun. Yet in comparison, I spent all day today staring at (and fixing) code from 2008.

Answer 13

I think the simple fact that you recognize this tension is a sign you are on the right path. The trade-off between "cheaper and faster" vs. "beautiful but costly" design is there at every step in a project; you have to manage your technical debt. What you have to recognize is that there is no such thing as the perfect design in the abstract; I heard someone say once that you could only appreciate whether a design is good or not if you knew what the constraints were. If the project needs to be completed fast, then that should be your goal, and the benchmark by which you measure the quality of your design. On the other hand, it's also important to have your client realize that there is no free lunch - and that typically, if you get it done faster/cheaper, it means they will incur some cost down the road (the "technical debt"). If that's what they want, that's what you should do - it's not your call.
I also think it's easier to learn to deliver "cheaper" code when you know what the "ideal" solution is, than the opposite. If all you know is hacking things together, it's hard to see what alternatives there are. If you start by seeing how you could do it "in a perfect world with no budget limit", you can more easily pick what trade-offs to make, and what parts are really critical, and what parts would be nice, but can be left for later.

Answer 14

There is definitely a compromise between elegant and slapping stuff together, but I do come down on the side of, "if you can't do it on time, then I don't care how elegant it is".

If I hired you, I'd probably appreciate your elegant style for the first month or two, but would quickly turn my focus onto your (self described) inability to actually get things done and shipped on time/budget. If you want to be really successful, get it done on time AND make it elegant. The inability to do both will hurt you in the long run.

Not everyone who wants their house painted needs Michelangelo to do it...sometimes (usually) it is just a paint job and that is all the client wants, and all they are willing to pay for.

Answer 15

Practice client-driven development.

The code doesn't matter. The product matters. Getting the product working for the client is what matters even more than the product itself.

Do not technically obsess - remember, Worse Is Better.

The only question is, how high does your process bar have to be to make the client happy, both today and down the road(which is the basic motivation for good code). Perfect code is appropriate in life-critical systems. Most other systems don't demand perfect code.

You're in a business. You're not doing this for art's sake. If you were, you wouldn't be concerned by this.

Get the job done to the client's satisfaction and move on. If you keep having to redo work, do it right the first time(but not stylistically perfect - just right).

Answer 16

The simple answer is that at the end of the day the only coding standards or best practices that matter are ones that save money/time. A lot of best practices are designed to save time over the long run by investing some time up front to save maintenance time in the future. No one can answer the question of whether what you are doing is good because it depends on the circumstances. Ideally what you should be doing is minimizing the cost of the code over the long run for them. Clients don't care if the code is written elegantly as long as it works (and works into the future). If your best practices are helping you do that then thats good, if they are not then they are probably bad.

Answer 17

I'm a very successful and productive programmer, I'll tackle your points 1 by 1:

• I tend to be more of a purist, scorning unelegant approaches to solving problems using code

  No need to ditch unelegant solutions, an ugly approach is appropriate if it meets performance requirement, is easily maintainable and easy to understand. Don't hold to dogma, one goto a month can save you a lot of headaches in particular situation.

• I tend to look at anything in a large scale, planning everything before I start coding, either in simple flowcharts or complex UML charts

  Planning everything before hand is useful, especially identifying potential pitfalls and show breakers. However, flowcharts and UML charts don't help a lot during programming. I will ditch any preconceived model as soon as I discover a better one while programming in the real world.

• I have a really strong impulse on refactoring my code, even if I miss deadlines or prolong development times

  There are two occasions when you should consider refactoring. 1, your code breaks every time you make a simple change because it is tightly coupled. 2, when you have free time near the end of the project.

• I am obsessed with good directory structures, file naming conventions, class, method, and variable naming conventions

  Define once, stick to it. I'm still using a few MFC conventions in WPF, it still works.

• I tend to always want to study something new, even, as I said, at the cost of missing deadlines

  Obviously there's a time to work and a time to study.

• I tend to see software development as something to engineer, to architect; that is, seeing how things relate to each other and how blocks of code can interact (I am a huge fan of loose coupling) i.e the OOP thinking

  You should consider being an analyst instead of a programmer, to be a good programmer you should see software development as production.

• I tend to combine OOP and procedural coding whenever I see fit

  It's a good approach, use the right tools for the right job, mix and match to achieve the best solution.

• I want my code to execute fast (thus the elegant approaches and refactoring)

  An elegant approach will produce the worst performance almost every time. One of the best generic way to increase performance is writing very long procedure with very short code lines. However, you should focus your energy on optimizing your calls to external libraries rather than optimize your own routines.

Answer 18

I tend to think you are going to have a really hard time keeping a real job in the real world. The real world is about getting software into the hands of the customer as quickly as possible. Sadly most of the other stuff management doesn't give a crap about. Working software wins in the real world every time, and by working I mean it runs and does something close to what the customer wants. Working correctly is a different story, most times. This isn't wrong by any stretch of the imagination. Working code that solves a problem can be ugly hacky and generally aweful from a theorical standpoint and still make the company just as much money as your late and incomplete code that is "elegant". There is an agile principal "You Ain't Gonna Need It". Just about everything in your list goes completely against this principal.

It doesn't have to be this way, but it is the majority of the time. Things like SCRUM can alleviate some of the mis-management issues, but in the end, the customer doesn't care about any of the OCD-ish things you list off. Moving files around in directory structures endlessly has no benefit to the customer.

The bottom line is if you aren't delivering working product when you said you will because of twiddling with time consuming reorganization and refactoring that doesn't actually contribute anything you will get a bad reputation of a twiddler. And senior staff with experience can spot a twiddler really quickly in interviews, and if you get in the door you won't last long when deliverable code isn't being produced. I have worked with guys who are more concerned about these things and installing and re-installing Linux every other week. They don't last long and get fired or are the first to get laid off because they aren't considered contributors to the team.

Refactoring should only be done when it provides some tangible benefit, that is when it is needed to fix a bug or enable adding a feature. If you have all this super over engineer design and no one ever touches the code after it is deployed, or touches it once a year maybe, then what did all those wasted hours of endless refactoring and missed deadlines gain you?

Just think about all PERL code out there that silently runs businesses around the world. Do you think the bean counters care about it being in PERL? Replace PERL with anything else and you get the same answer.

Answer 19

You love your craft and want to improve yourself with it. Nothing's wrong with that.

But I think you're trying to use all these concepts when you haven't really mastered each one. It's like playing basketball when you don't know how to play but read a lot of how to do advanced techniques.

You have to start with your basic fundamentals (in your example, this would be OOP).

Do the minimum necessary to get the job done using just your basic fundamentals. This will be your safety net.

After you get the job done, you can refactor the code to one-by-one reflect your other coding style. The purpose of this is to practice your other coding standards.

As time passes, you'll find yourself getting faster coding with just your basics. As your basic fundamentals increases, you'll find it easier to use your other coding standards.

I am in a major stump right now.

I think you are unhappy because the reward you're expecting is not the same as the amount of work you put in. Clients not noticing how deep you planned their software is just the trigger for your unhappiness.

The excuse I often receive is clients don't care about how you write the code, but they do care about how long you deliver it. If it works then all is good.

People loves bacon. But people don't like to see a pig being slaughtered to make bacon. And they want their bacon now!

Coding is like this. As long as they see the results, its fine by them.

In my own experience, the only time clients becomes interested in the code is either they are a) technical or b) something's wrong and its affecting the software.

Client a are rare, but they exists and are fun to work with. Client b is a bad experience, but it will make you a better programmer.

Now, did my "purist" approach to programming may have been the wrong way to start programming? Should I just dump these purist concepts and just code the hell up because I have seen it: clients don't really care how beautifully coded it is?

No. You stick with what style your comfortable in and improve yourself with it. Just don't forget your basic fundamentals.

• I want my code to execute fast (thus the elegant approaches and refactoring)

I have to take issue with this one particular bullet point. Please don't use premature optimization.

You should optimize your code only when you've profile the speed of your program. Why? Because you have no idea how fast or slow a particular code will be compared to the rest of the software.

If a piece of code takes 2 seconds to run and it only runs once, then there's no need to optimize this. If you think a code would take a long time that you should optimize it immediately, then it would just be wasted effort if it turns out that wasn't the bottleneck.

Answer 20

I will take a learn-by-mistake approach for my answer.

Balance between doing it by the book and code & fix is something you gain through experience.
Fast and good enough usually gets the job done for bosses and clients.

The following tries to be an optimisc point of view of working under a "code-it-so-we-get-paid" boss conditions. To merely remind why good practices were created. To learn the hard-way.

If your boss is "code-it-so-we-get-paid" oriented, follow his approach and code faster to learn this programming "school" (but not do adopt it), just to know the dark side :-). It will be a new way of thinking, hard for you at first. If you do it fast and well enough, no harm done (probably for a time). When this programming style gives you headaches (probably in the forecoming months), you'll know why there are good practices and when to apply them better. You'll also understand more developer jokes :-). You'll be learning how mistakes are done and reason how to avoid them and fiercily reject coding idioms/patterns that leads to them the next time. This will get you experience. If you still need/keep this job, sometimes you will be unhappy because of this style, so code academically correct and nice to elevate your self-esteem.

All of this, without mentioning comercial operatives coming to nicely ask you about time estimation if you are not "protected" by your boss. This environments tends to be messy.

Good judgement and experience will tell you when to do it right or just good enough but fast. Know when to use a particular development cycle like cascade style, spiral, code&fix, prototyping, or etc. Base your decision by knowing their pros and cons. That's the key for you.

If you can't work at your job, there are other bosses, works, pairs to work with.

Well, I must say, after saying "follow his approach code faster", I can't avoid think on Palpitane telling Anakin Skywalker about the dark side... So, remember, just know about code&fix, but don't get (too) corrupted by it!

Answer 21

Thanks Ygam for posting such a nice question and it is really great to see everyone sharing thoughts on an issue that surely has bugged every software engineer at some point of time in his/her career.

It really gave me confidence to see that there are many people who thinks like I do. I was assigned a project about a year back when I neither had OOP skills nor much knowledge about .NET. Yes, I had a rich experience about business apps and a strong procedural programming background of 12 years. We were to develop a "product" and not a "project" and I wanted to do it right from the very beginning. Even with my experience and perfectionist attitude backing me up, it took me more than a year to get to the deep areas of Architecture, Design Patterns, OOP modelling, Loose Coupling, Structuring and C#/Visual Studio itself.

Believe me, in this 14-15 months, I was often tempted to "Get things done" the procedural and easier way and just deliver the product, but the "purist" attitude prevented me from doing so. Every corner that I was stuck up at, had an "easier way" to just make it running. I opted for the harder but elegant way.

But as "Vivin" pointed out, at the end of this long, sometimes humiliating period of not being able to "show" the product, I now have a robust framework which can handle a lot of things in a reusable manner that every "muggle coder" (refer Harry Potter) will either re-think every time, or re-implement everytime, often differently causing longer delivery timelines in the long run. It's like the famous race of the rabbit and the tortoise.

My framework has followed "standards" which gives me assurance and a good sleep. Of course I also believe that this strategy works better while developing "product" and while in projects we sometimes have to use a "code and forget" strategy just to meet the deadline. But if somehow, by convincing the management, we can get the framework done, every next "project"/"product" benefits from it.

To balance things, both "standards" and "delivery", I have taken a different approach. I think "Purists" like us should be more preachers and monitors. Hence I have taken in a handful "coders" who just follows the standards while I continue to "develop and monitor" the standards. This approach is helping me a lot to maintain standards in my organisation as well as keep deliveries rolling.

Happy coding.

Answer 22

Stick to the standards since they are very important.

Correct me if I'm wrong, but writing re-usable OO code should take a lot less time than just putting some code together hoping it will work.

Answer 23

It seems that you could fit in well in a very large projects, where scalability, code legibility, performance and documentation really matter.

When it comes to smaller ones, your perfection could mean being not effective or producing too much formals around something that is not too complex and should just work.

Answer 24

The contractor on my project took your colleagues' approach, and it keeps biting us every other day. The unmaintainable and non-OOP codes have to be rewritten. The bad performance affects us badly when the code is called 100k times during a weekend migration and eventually has to be rewritten as well. Everyday I curse the contractor to a painful death for the pain he inflicted on me. :-|

Answer 25

My answer is to keep doing what you're doing with one caveat: You realise that getting a project done in a time frame is it's own sort of elegance.

The fact that you keep wanting to re-factor your old code tells me a few things. One is that you're not doing it right the first time. The second is that you're realising that you're not doing it right and figuring out the right way. Both are very important steps in learning something new. The final step is not making that same mistake twice.

Four years from now when presented with a problem you probably won't need the flow charts or UML diagrams, you'll know instinctivly how you'll build your project, because you'll have made all the mistakes before, and gotten your feet wet with enough tools that you can pick the right one for the job. Eventually you'll get to the point where you do a job once, look at it, and say, "I couldn't have done that better."

That's where you want to be, and cutting and pasting code from the internet in a mad rush to get projects out the door won't get you there. It might make your clients happy, but with enough time and practice you'll be able to match those other guys speed, and do it right. Keep that goal in the back of your head for the next few years.

Answer 26

Each the (of your)purist approach have some reasons.
If you know the reason, you can choose when to use them and when to throw away.

• The good performance, need in programs that need scalability.
• Good code structure is important when you need to add new features and handle with large source code.
• Learning new things its contribute for your next projects, current project pay for your learning curve.