locked
10 golden rules of programming - a living discipline RRS feed

  • General discussion

  • To begin, I should talk a little bit about my background. Beginning current and  moving backwards in time, I currently work as a lead developer in a national conversion project for one of the largest banks on the globe whose name will remain confidential for obvious reasons. Prior to this, I was a senior software engineer for American Express in charge of a redesign for the largest rules process engine in the market as well as new ad-hoc development. Prior to that, I have worked for several government agencies as well as major utility companies, start up businesses, and have taken on uncountable freelance projects having miles of .net code.

    Throughout this rollercoaster ride, I've held the titles of DBA, Project Manager, Software Engineer, Network Administrator, Technical Writer, and have trained a few development teams. This versatility has contributed immensely to my engineering background and allowed me to put together the following list: (in no particular order)

    1.     Don't re-invent the wheel.

    Too often, our better judgment and ethics play a major role in our job. Is there always a better way to do things? Most often, yes. Should we change it? Most often, no. In larger environments, there are many links to many resources that touch a poorly written piece of code. Without fully understanding the bigger picture, changing 1 variable could result in breaking the entire system. Equally, a stand-alone piece of code that is working in production, most of the time, should never be touched, unless, of course, it is producing undesired results or is performing poorly. Outside of that, let sleeping dogs lie. You'll be glad you did. One small piece of code can quickly turn into a full blown project before you know it. I suppose it's entirely at the mercy or your work load, but consider this before your ambitions take control.

    2.     Keep things as simple as possible but not simpler.

    It's very easy to sit down and start hammering out picturesque OOP, layering the onion with well justified abstraction interfaces, massive exception handling modules, explosive stored procedures, gigantic SSIS/DTS packages, intricate encryption algorithms, and patent worthy designs. Don't do it! Unless you're going to be the code monkey for the company until retirement, you're not only creating a difficult maintenance environment for your limited time there, but you're creating a nightmare environment for the next engineer. If you haven't experienced a mole hill that turns into a mountain, you will, and when that happens, you'll appreciate a simple design that gets the job done. Equally, don't be satisfied with a skeleton design that's vulnerable to security risks or falls victim to end-user misinterpretations. Decide on when enough is enough before you commit to the keyboard.

    3.     Learn from others mistakes, not your own.

    Forums are great place to begin but nothing competes with real world experience. The forums are a good learning environment, even for seasoned engineers, because simply studying the habits of other developers expands your mental dictionaries. Coincidentally, you also learn your own weaknesses while your noticing the mistakes of others. When you can honestly say, "Hindsight 20/20 is for someone else, " you've reached programming enlightenment.

    4.     Performance has no competition.

    Not much explanation required here. There are many current arguments that preach TB hard disks and GB's of RAM as justifications that datatypes and performance-enhanced code are no longer a concern. Wrong. This is completely ignorant. Companies still have budgets and they generally don't include expanding a disk array, adding a processor or a stick of RAM. Quite the contrary, many server settings and applications are being designed to take full advantage of free resources. For example, by default, SQL Server will consume all hardware resources to complete a task. If I had a nickel for every junior DBA that looked at the cpu usage as some form of measurement and scratched their head on the overhead, well, I could afford a retail version of MS Office 2007. :) Code optimization is a specialty on its own. There's a reason there are entire books dedicated to it and it's not entirely due to an author's vanity.

    5.     Bug free code is more important than clean code.

    This speaks for itself. Many new to the field want to write attractive and easy-to-follow code. There's nothing wrong with that and it is a good practice. However, it is not as important as code without bugs. Before you jump out of your seat, let me comment that both are desired and both can coexist. My point here is that learning to write bug-free  code is a discipline that exalts OOP or n-tier architectures and only time and experience will give you the ability to prevent issues such as implicit conversion errors and overflow exceptions. Now I'm not saying it's not an attainable skill at an early stage of development, I'm simply saying that it is often not the focus of the development life cycle but should be and will be the more you enhance your skills.

    6.     Begin with an end in mind

    Bet you thought this was a no brainer didn't you? One of the funniest comics I've ever read...it was Dilbert or Far Side, had a manager and 2 programmers. The manager leans over the programmers shoulders and says, "You 2 start coding and I'll go figure out what they want." Very Funny. Haha. It happens all the time. Agile/Scrum, Waterfall, and Interative are overlapping methodologies and are starting to blend colors. Yes projects can be never-ending but give the development stages proper documentation and an identity. This stage identity is a communication medium between you and management, and believe it or not, the ability to communicate and translate programming endeavors to business terms is becoming an increasingly desired skill almost more so than the programming itself. But that's another thread. To close this one, get management or the customer to sign-off on a finite design long before you employ the keyboard. This is your insurance policy and nice folks that don't do this are the ones who work late hours, holidays, and weekends.

    7.     If it's not broken, don't fix it.

    Just don't do it. Even when you think you can improve upon existing code. Don't. If it works and fulfills the requirement and is in no way offensive (key point here), let it be. Resist the selfish desire to improve the last programmers code. He/she doesn't care and neither should you. You'll have plenty of time and opportunity to write your own code and guess what...the programmer following you will see pinholes in your code that they think need improvement...but the good programmers will let sleeping dogs lie.

    8.     First seek to understand, then to be understood.

    No Dr. Phil didn't say this but he should. It holds true in all relationships both personally and professionally. Never assume that because you've developed an inventory management system at a previous job that your current employer wants or needs the same design. Although similar in content, the programming can be as different as night and day. Now don't get me wrong, your input is valuable and should be brought forward, but only after your are crystal clear on the requirements. The art of paraphrasing will make you many friends in the programming world because it shows management that you're not only listening intently but you also care about what you do outside of the keyboard. As hinted above, communication skills are slowly superseding programming skills and for good reasons. A brief why...because it's easier to take someone with good communications skills and teach them programming than it is to take a programmer and teach them communication skills. Let's leave it at that for now.

    9.     There's a place for everything and everything in its place.

    This is a practice that has allowed me to be shortlisted and hired over even the most advanced developers and it's because you must understand and take advantage of the benefits of each environment. For example, SQL Server is designed and optimized to query and reduce records. .Net is not. So if the goal of your code block is to filter a recordset, use the best tool for the job for both performance and optimization reasons. Too many times I've seen SQL developers code procedural-based approaches in a stored procedure because they don't know how to write .net code and .net programmers writing set-based approaches in OOP when it should be in a stored procedure. Read the next sentence carefully. Don't be a victim of your own ignorance but equally, don't bother learning something you'll never use. Simply question and research the best environment for the task at hand and learn something new.

    10.  Scalability is next to godliness.

    No sooner than you design and deploy an application that you were told and assumed was a throw-away application, it suddenly becomes valuable. It happens all the time. Yes, there are time constraints and other pressures that force us to discard good practices to meet deadlines, but never enough to ignore future developments. It takes only seconds to build a reusable class, compile it to a .dll, and add it to your library or better yet, implement a .dll from an old project because you thought ahead. So instead of copying/pasting or simply rewriting the same function over and over again, start building your own .dll libraries. This habit will allow you to later always ensure that your developments are scalable by giving you a quick and effortless foundation to build from.

    Disclaimer: There are others, of course, but I have reduced and refined the list to 10. This list is completely subjective and is not all inclusive.

     


    Don't bother learning something you'll never use.
    • Edited by Adam_Turner Thursday, June 17, 2010 6:59 PM
    Thursday, June 17, 2010 6:13 PM

All replies

  • You forgot:

    11. Hound and persecute those that don't conform.


    Regards from Livingston, Scotland
    Thursday, June 17, 2010 6:27 PM
  • #5 is wrong and there are examples of companies who created some wonderful bug free code that couldn't adapt to changing requirements and slowly the company went under. Clean code is maintainable code, it's readable code, it's reliable code. Bug free code does not lend itself to clean code but clean code lends itself to bug free code. Clean code takes into consideration one of the most important users of the software... the next developer. Clean readable maintainable code should be the goal of every good developer.

    I also disagree with the comment that developers new to the field want to create clean code; quite the opposite actually new developers don't even think about the quality of their code all they want is to see is the expected result. Many developers don't care about writing clean code and that's a shame.

    #7 as well is a bit ... 'Resist the selfish desire to improve the last programmers code. He/she doesn't care and neither should you' ... does your employer know that? I wouldn't hire a developer who thought that. That's a recipe for software rot. If you don't improve on code that's a little nasty then the software will gradually rot until someone shouts rewrite. If you had said 'if it's not broken then don't fix it' because you may break it then I'd have recommended a solution.


    You know I get the impression your one of those developers that hacks on a system until it gets into a mess. Eventually developers realise there are some smells in the system, bugs become more difficult to fix, new fixtures are more difficult to add, and rather than fix those smells you move on to a new company or a new position and repeat the process.

    Thursday, June 17, 2010 8:15 PM
  • Derek,

    I really don't do much development these days. I fill more of a consulting lead role handling mainly code reviews and project designs.

    The above, as the disclaimer states, is not all inclusive. There are systems that require migrations and full redesigns but they fall into the generalized categories above.

    -Adam


    Don't bother learning something you'll never use.
    Thursday, June 17, 2010 8:31 PM
  • #5 is wrong and there are examples of companies who created some wonderful bug free code that couldn't adapt to changing requirements and slowly the company went under. Clean code is maintainable code, it's readable code, it's reliable code. Bug free code does not lend itself to clean code but clean code lends itself to bug free code. Clean code takes into consideration one of the most important users of the software... the next developer. Clean readable maintainable code should be the goal of every good developer.

    When you're in a senior role where you're reporting to non-technical upper management, they honestly don't care about the developers ethics. If there are bugs, they want to know why. If they are consistent, you're replaced quickly. Clean code is nice in a junior role if your team lead is also programmer but they'll quickly preach to you the above statement because they have to report to upper manamegement. For fortune 500 companies, your job is to program for the end-user. When you deploy into production with a bug, all ____ breaks loose and if you're excuse is, "I had the programmers best interest in mind." Adios. I understand where you're coming from but as I have already said, clean code and bug free code can co-exist and being in the habit of writing clean should be common practice. I agree. But what should be and the reality of it all is not the same.

    I also disagree with the comment that developers new to the field want to create clean code; quite the opposite actually new developers don't even think about the quality of their code all they want is to see is the expected result. Many developers don't care about writing clean code and that's a shame.

    New developers have the "desire" to write clean code but not the ability. This is where the mentorship of a lead developer plays an important role. Foreseeing potential trouble areas (bugs) is a time-wearing experience that typically is spotted by the lead and returned to the developer after a code review. This is just a learning process.

    #7 as well is a bit ... 'Resist the selfish desire to improve the last programmers code. He/she doesn't care and neither should you' ... does your employer know that? I wouldn't hire a developer who thought that. That's a recipe for software rot. If you don't improve on code that's a little nasty then the software will gradually rot until someone shouts rewrite. If you had said 'if it's not broken then don't fix it' because you may break it then I'd have recommended a solution.

    In most cases, there's no time. As I have said and underlined, if it's not affecting anything, just leave it alone. When you have deadlines to meet and you push out a milestone because you're fixing something that's not broken or not part of the scope, your team lead will be very popular at the next management meeting. If you continuously push out milestones because of unauthorized rewrites, well you get the point. As a side note, unless you have a very strong case for rewrite, it is almost never approved.


    You know I get the impression your one of those developers that hacks on a system until it gets into a mess. Eventually developers realise there are some smells in the system, bugs become more difficult to fix, new fixtures are more difficult to add, and rather than fix those smells you move on to a new company or a new position and repeat the process.


    Quite the contrary. I leave it alone. As far as bug fixes, well they are all addressed and resolved. There is no smell in the system. When bugs are encountered, they are fixed in UAT before they get into production. If one slips through QA, a trouble ticket is assigned to you and resolved immediately. Derek, I understand your point-of-view because I've been in your shoes. Your focus is on good coding practices and that's great. There are other points of view and other environments. When I interviewed for my current role, the first question from the VP was, "What's more important? Clean code or bug free code and why?" Remember this is a bank where the software is used by 1,000's daily. One bug in banking software and you can imagine the disaster. The answer really depends on who's asking and what role do they perform. Adam
    Don't bother learning something you'll never use.
    • Edited by Adam_Turner Thursday, June 17, 2010 9:46 PM spelling
    Thursday, June 17, 2010 9:24 PM
  • Hi Adam, need to keep this brief some idiot has booked an 8am meeting tomorrow... I could go on for hours with this discussion and the end of the day it's a difference of opinion and that's cool.

    I am senior and do report to upper management :) and your right they don't care about the code they only care about $$$ where bugs = -$$$. Your right but the more I think on this the more it feels like you don't practise agile development. I rarely talk about bugs with the management at these meetings, that's usually sorted out before then.

    Adam, I understand your point-of-view because I've been in your shoes.   :)  I changed shoes.

    If someone asked "What's more important? Clean code or bug free code and why?" I would answer both, they are not mutually exclusive.


    Developers who I know that have worked in banks describe it like yourself as well. Call centres too.... lots of pressure placed on the developer just to get the job done. Adrenaline junkies..

    Maybe Adam we have different opinions on what clean code is.

    Thursday, June 17, 2010 9:59 PM
  • Derek,

    I would say not so much differences in opinions as it is differences in experiences which contribute to the opinions.

    ...but feel free to contribute your experiences/opinions when you have time.

    Adam


    Don't bother learning something you'll never use.
    Thursday, June 17, 2010 10:04 PM
  • Gee, This was a surprise. I mean the way your guesses in giving advice told books about you as well as the training. You are headed towards management after all?

    ·         1.     Don't re-invent the wheel.

    I guess purveyors of applications code have this dilemma but real systems people don't or I should be honest- didn't. But it's all largely been invented now for the time being.

    Largely I fine that oop is still an application persons area. Yes, exec people could do it also but right now we need speed because of applications programmers and their lack of concern about performance.

    2.     Keep things as simple as possible but not simpler

    I know there has to be a reason for writing this other than writing tires dicta. but i fail to detect it.

    3.     Learn from others mistakes, not your own.

    Again, there has to be wisdom here...but it's defies detection.

    4.     Performance has no competition.

    Gee, I thought I'd keep this in here and look at the justificatons...they are all based on capital or a managers dream.

    Not much explanation required here. There are many current arguments that preach TB hard disks and GB's of RAM as justifications that datatypes and performance-enhanced code are no longer a concern. Wrong. This is completely ignorant. Companies still have budgets and they generally don't include expanding a disk array, adding a processor or a stick of RAM. Quite the contrary, many server settings and applications are being designed to take full advantage of free resources. For example, by default, SQL Server will consume all hardware resources to complete a task. If I had a nickel for every junior DBA that looked at the cpu usage as some form of measurement and scratched their head on the overhead, well, I could afford a retail version of MS Office 2007. :) Code optimization is a specialty on its own. There's a reason there are entire books dedicated to it and it's not entirely due to an author's vanity.

    And...if the author showed any sign of reading them....

    5.     Bug free code is more important than clean code.

    "Don't reinvent the wheel", obscures neatly many complexities of moderately complex code but when you are developing asynchronous systems on clusters of machines, suddenly the levels of complexity increments to the point where that is fairly meaningless advice.

    6.     Begin with an end in mind

    That's a standard business where I come from. Is there something remarkable about it? I notice already the emphasis is on business practices and here I thought this was a technical forum.

     

    7.     If it's not broken, don't fix it

    This is definitely mixed advice and would never "float" design - wise in modern exec development.

    8.     First seek to understand, then to be understood.

    Actually, "a communication skill" is important but it's a beginning skill.  "A communication skill" and one dollar and thirty five cents will buy you a reasonable cup of coffee.

    9.     There's a place for everything and everything in its place.

    "Read the next sentence carefully. Don't be a victim of your own ignorance but equally, don't bother learning something you'll never use. Simply question and research the best environment for the task at hand and learn something new."

    Of you know what's available before getting into the study of an entity.

    10.  Scalability is next to godliness.

    Notice how we've lept into a technical area which is scalability?

    I can see why Adam attacked me. Even after being in a car accident I must scare the Bejesus out of him.

     

    I'll do my best to leave you alone Adam.

    Renee

    Friday, June 18, 2010 2:47 AM
  • Adam (and others)

    Very nice list. I agree with most points - especially point 2 - read my signature, but like Derek, I think that point 5 and 7 need a comment from me too. Bug free code, now or in the future?

    There is no doubt that bug free code is more important than clean design here and now, but if the code is not clean, you will not be able to maintain it and write bug free code in the future - read the last part of my signature. Don't wake a sleeping dog. Well if that dog is in your way towards a better design, it may be necessary.

    I have just been in that situation during the development of our new fieldbus Max-i - see www.max-i.org . I wanted to add a new feature and had two choises:

    1) To let the dog sleep and add some not very pretty budding.

    2) To go right down to the basement and change something there knowing that it would be a wasp's nest to touch because almost the entire system depended on that.

    I choosed no. 2 and I am glad I did. Now the system is very clean and maintainable. Because I have always choosen #2 in such situations, I was able to overview that firmware and make the necessary changes!

    Look at Windows. It has been an endless budding, which has lead to code nobody are able to overview. This has coursed a never ending row of serious safety holes (in the order of 400 by now in XP), which is exactly what you get if you loose the overview - but of course, it is the way to earn money if you are so lucky that your products have become a de-facto standard.

     


    Everything should be made as simple as possible, but not simpler. Any fool can write code that a computer can understand. Good programmers write code that humans understand.
    Friday, June 18, 2010 8:07 AM
  •  

     

    4.     Performance has no competition.

     

    Not much explanation required here. There are many current arguments that preach TB hard disks and GB's of RAM as justifications that datatypes and performance-enhanced code are no longer a concern. Wrong. This is completely ignorant. Companies still have budgets and they generally don't include expanding a disk array, adding a processor or a stick of RAM. Quite the contrary, many server settings and applications are being designed to take full advantage of free resources. For example, by default, SQL Server will consume all hardware resources to complete a task. If I had a nickel for every junior DBA that looked at the cpu usage as some form of measurement and scratched their head on the overhead, well, I could afford a retail version of MS Office 2007. :) Code optimization is a specialty on its own. There's a reason there are entire books dedicated to it and it's not entirely due to an author's vanity.


     

    Adam,

    I agree completely with everything you wrote, except the above one, in the way you have stated it does count for every situation.

    This 4th one can be seen as a reason that the 9 other ones are wrong.  (And that I do not agree with you). Performance has competition as long as it counts for the goal.

    For instance, if a program uses 120Mb and the application is meant as only application on 2Gb computers, there is no need to optimize that. Tomorrow you cannot get anymore 128Mb chips anymore.

    I've seen too often many developers long time busy for instance to get an internal part of an  desktop applications 2 picoseconds faster. While they forget to take efforts in the way they get data as efficient as possible over the line.

    I don't assume we disagree, but as it is currently stated, it can give in my idea a wrong impression.

    We see in the forums also that searching for performance gain in places where it is not important anynore in 2010 (luckily more by C# developers then by VB developers). I assume that you have done bank clearing with punching cards (or tapes), I think that the same performance delimiters are still the same for all current applications around that.  However, a game on an X360 has other places where performance is important.

    :-)

    Nice article by the way,

    compliments

    Cor

    Friday, June 18, 2010 9:24 AM
  • Well,

    I thought my disclaimer woud give me a safety net, but I'm glad it didn't. It is nearly impossible to pinpoint every point of every issue in 10 simple bullets. It is also nearly impossible to avoid differing opinions. There is always room to expand.

    The goal of this article was to step away, for a moment, from the code monkey approach of the "Why doesn't this code work..." idealism and dig deeper into the broader spectrum of approach. The aim will determine the destination of the arrow and it's difficult to pull out the arrow once it's stuck in a tree.

    I expected Renee Culver to take the brevity number-by-number 1/2 sentence response approach to compare programming 30 years ago to programming today which is an apples to oranges comparison so I'll just ignore her senseless babble.

    Carsten and Derek,

    I really can't stress enough that I support clean code. Yes maintenance and scalability would be a nightmare without it. My point of view was coming from a very highly transactional environment where 1 bug would be devastating so a lot more emphasis is placed on it over code cleanliness. Yes there are other environments where a bug or two can wait because the impact is minimal, in that case, the maintenance environement becomes a higher priority. There is always an "it depends" scenario.

    Cor,

    Yes there is some overlapping contradictions in the list. I expected that. I couldn't find a way to avoid it and not sure that I wanted to. I beleive Walt Whitman said it best, "Do I contradict myself? So be it. I contradict myself. I am large. I contain multitudes." As the seasons change, so will the meaning and importance for each bullet.

    Thanks for the responses all (except for wackjob Renee Culver. Crawl back under your rock please.)

    -Adam

     


    Don't bother learning something you'll never use.
    Friday, June 18, 2010 11:49 AM
  • Adam,

    I don't want to take the thread off course but I think everyone will enjoy hearing about something that happened to me some time back.

    I applied to a position for web programming for a bank, quite some time back.  On the application they ask the "goofy" questions like "What is your ideal job situation?".  I don't like to lie on applications, I just don't see a point in it; so, I said basically that I was looking to work in an environment that focused on quality and not quantity.  To me that sounds like a potitive, but after hearing you describe the situation with the bank you work for, what I was looking for seems like a bad thing.

    Reason I say that, is I don't even recall getting a response back so fast from any employer ever, telling me that we didn't "have a match".  I think they read the comment and said "NO; NEXT!".  This was not a position that required a lot of experience either.  Perhaps they wanted someone they could "mold to do their bidding".

    What I have learned in my short time on this planet is, someone will tell you they want quality, but they will drop you at the hat for someone cheaper, even if they know the quality won't be as good.  If companies could rent coders at the local surplus store, I think they would.

    Ok well I will leave it at that.  Thought you all might find it interesting.


    FREE
    DEVELOPER TOOLS     CODE     PROJECTS

    DATABASE CODE GENERATOR
    DATABASE / GENERAL  APPLICATION TUTORIAL
    Upload Projects to share or get help on and post the generated links here in the forum
    www.srsoft.us
    Friday, June 18, 2010 1:17 PM
  • Jeff,

    Interesting story. Thanks for sharing.

    There is typically some HR related questions that you have to wade through to be shortlisted for the 2nd or 3rd interview. My experience has typically been 3 part interviews. Part 1: HR resume review 2: More technical deail on your resume roles 3: Meeting the team and bombarded with a wide array of technical questions and scenarios. It's a very long drawn out process.

    All I can really say is that you have to consider the position, the need, and the environment. I had to interview with American Express 3 times before I finally landed a senior role. I asked the VP what was wrong with my previous attempts and his response, "We felt that you would be bored and leave for a more challenging role." So you never know "why" there's no match. Assuming why is never good. I thought your answer was fine and different companies have different response rates.

    More recently, I interviewed with US Airways for an ASP.net developer position. Again 3 parts. After part 2, they wanted me to interivew for a SQL Dev position instead. On part 3, the DBA didn't have the courtesy to attend the interview. He was driving down the street on his cell phone asking me questions. After I corrected him 3 consecutive times, I realized I didn't want to work there. Funnier yet, as I literally argued with the DBA on the abuse of explicit transactions locking up the server and domino-ing back and crashing the network, the network admin got a call and had to leave the interview and reboot the server because the network crashed. Haha. True story. Not a place I'd ever want to work.

    Keep in mind that some companies interview for advertisement purposes only with no intention of hiring anyone. Many departments want to give upper management the impression that they're overworked and need additional resources then turn around and say no interviewee is competent to fill the role. It's just a smoke and mirrors facade.

    As far as renting coders, well, that's just a fact of life. Programming isn't rocket science. It's a trade no different than carpentry. It just pays a little more.

    ...and yes a little off topic but atleast it's not "What's wrong with my code?"

    Adam


    Don't bother learning something you'll never use.
    Friday, June 18, 2010 1:51 PM
  • Adam, salute that.  Nice topic, good reasoning.

    I agree with the others about #5 and #7.  The two are so intertwined that they are almost impossible to identify as separate issues.  #7 is the single biggest fault that I see developers make, the fear of 'breaking' code.  Poorly written code breaks, well written code doesn't. 

    In my experience, well written code isn't simply written out start to finish.  TAA DAA.  Nah, stuff evolves into well written code. 

    Thanks for the help you provide in answering questions for perfect strangers.  Happy Coding.

    Rudy  =8^D


    Mark the best replies as answers. "Fooling computers since 1971."
    Friday, June 18, 2010 10:02 PM
  • Gee, This was a surprise. I mean the way your guesses in giving advice told books about you as well as the training. You are headed towards management after all?

    ·         1.      Don't re-invent the wheel.

    I guess purveyors of applications code have this dilemma but real systems people don't or I should be honest- didn't. But it's all largely been invented now for the time being.

    Largely I fine that oop is still an application persons area. Yes, exec people could do it also but right now we need speed because of applications programmers and their lack of concern about performance.

    2.      Keep things as simple as possible but not simpler

    I know there has to be a reason for writing this other than writing tires dicta. but i fail to detect it.

    3.      Learn from others mistakes, not your own.

    Again, there has to be wisdom here...but it's defies detection.

    4.      Performance has no competition.

    Gee, I thought I'd keep this in here and look at the justificatons...they are all based on capital or a managers dream.

    Not much explanation required here. There are many current arguments that preach TB hard disks and GB's of RAM as justifications that datatypes and performance-enhanced code are no longer a concern. Wrong. This is completely ignorant. Companies still have budgets and they generally don't include expanding a disk array, adding a processor or a stick of RAM. Quite the contrary, many server settings and applications are being designed to take full advantage of free resources. For example, by default, SQL Server will consume all hardware resources to complete a task. If I had a nickel for every junior DBA that looked at the cpu usage as some form of measurement and scratched their head on the overhead, well, I could afford a retail version of MS Office 2007. :) Code optimization is a specialty on its own. There's a reason there are entire books dedicated to it and it's not entirely due to an author's vanity.

    And...if the author showed any sign of reading them....

    5.      Bug free code is more important than clean code.

    "Don't reinvent the wheel", obscures neatly many complexities of moderately complex code but when you are developing asynchronous systems on clusters of machines, suddenly the levels of complexity increments to the point where that is fairly meaningless advice.

    6.      Begin with an end in mind

    That's a standard business where I come from. Is there something remarkable about it? I notice already the emphasis is on business practices and here I thought this was a technical forum.

     

    7.      If it's not broken, don't fix it

    This is definitely mixed advice and would never "float" design - wise in modern exec development.

    8.      First seek to understand, then to be understood.

    Actually, "a communication skill" is important but it's a beginning skill.  "A communication skill" and one dollar and thirty five cents will buy you a reasonable cup of coffee.

    9.      There's a place for everything and everything in its place.

    "Read the next sentence carefully. Don't be a victim of your own ignorance but equally, don't bother learning something you'll never use. Simply question and research the best environment for the task at hand and learn something new."

    Of you know what's available before getting into the study of an entity.

    10.   Scalability is next to godliness.

    Notice how we've lept into a technical area which is scalability?

    I can see why Adam attacked me. Even after being in a car accident I must scare the Bejesus out of him.

     

    I'll do my best to leave you alone Adam.

    Renee


    Renee, After reading your witch hunt in this other thread http://social.msdn.microsoft.com/Forums/en-US/suggest/thread/b48656f1-8eb7-4c5e-8766-258032e5b315 it is you that seems to be on the attack.

    Subnet Calculator / Planner      Serial Port
    Saturday, June 19, 2010 1:16 AM
  • Yes dbasnett,

    Renee is clinically disturbed. Honestly she is. He has the mind of a child. She will set fire to your house then cry victim because she stubbed her toe while she was dumping the gas.

    It's very sad bordering pitiful, but I'm used to it.

    Adam


    Don't bother learning something you'll never use.
    Saturday, June 19, 2010 5:16 AM
  • Yes different experiences is probably a better way to put it. Here are the experiences that formed my views on points #5 and #7.

    Two projects ST and RB. Both these projects are hailed by upper management as being a success, ST saved thousands, and still is (it's saving a fortune), by streamlining the coal and oil power plant design and performance process, while RB helped earn a couple of million from a nuclear power plant inspection project (RB secured the contract). I was lead developer on both these projects.

    ST was developed using 'traditional' waterfall software development methods while RB was done using agile methods. Lets start with ST...

    When ST was developed we developed it without giving much consideration to clean code, we were too busy to clean the code, too busy adding in new features and fixing bugs on those features. When any bad code was found we coded around it, if it ain't broke don't fix it right?. Just writing that last sentence gives me shivers, but that was what happened. Bug free code was more important than clean code. There was a big design up front and we coded to that design, when requirements changed we forced them in under the constraints of the design, changing the design a little bit to accommodate the feature if it could, and we had bug fix after bug fix to contend with.

    Ok that all sounds rather bad, am I just highlighting the bad points? The project was a success though; users loved it and what followed was the inevitable feature creep... can it just do this, lets add this, how about it does this as well.... these things were never originally planned for in the original design. Slowly the strain on the design was obvious and the time to add new features got longer and longer. There wasn't all that much wrong with the original design, it was layered and it was domain driven and new developers on the project understood it without much problem. It wasn't designed to be a mind reader.

    Now for RB...

    RB was a heavily audited project. If a bank software fails some money is lost, if a nuclear plants software fails... yes. So we had all sorts of management watching this one it was claustrophobic and perhaps not the best time to risk the first agile development I'd ever done, but I done it anyway. :)  During development the goal was to keep everything as clean as possible and have test coverage as high as possible by doing test driven development. If anyone came across bad code it got cleaned. The project ended up with much shorter method and a much more flexible design. Since we had coverage reports and a cleaner code base we had much better reporting up to higher management. We could actually show parts of the code to prove certain contingencies were covered. Showing code to management... never thought I'd see the day!

    There was never more than two or three bugs in the system and those were easy fixes. But then the bombshell... we need to change the original requirements, a redesign.... no problems the code was so readable that the redesign was straightforward and we had the safety of a test suite... 2 iterations later and the redesign was done and no bugs in any of the previous code. What a joy that project was!! A redesign without a rewrite. Again user requests came in, feature creep, but it was easier adding them in, the code was far more adaptable and maintainable, and alltheotherables. It was great...


    So ST is still going, someone else is leading it now, but no code clean up is happening, bugs are still happening and it's costly adding in my features, it's still a success but it's showing signs of code bloat.

    RB, was handed over as well and has had no bugs in production what so ever! the new lead developer complimented the code saying it's the first time he's actually been able to read the design from the code. First time that has happened.

     

    Adam, my opinions on clean code and fixing horrible code came about because of these two projects. Since RB was a joy to work on regardless of management towering over us and auditing our every move I have to say in my experience clean code is more important than bug free code as long as the clean code doesn't have any bugs in it (which is easier to tell because it's cleaner). I know your rules are generalisations based on current circumstances but the above is why I disagree with the points 5 and 7.

    Also I don't like 'Don't bother learning something you'll never use.' but I'm not going to get into that. Well it's time for the World Cup now.... later.

    Saturday, June 19, 2010 11:50 AM
  • "I expected Renee Culver to take the brevity number-by-number 1/2 sentence response approach to compare programming 30 years ago to programming today which is an apples to oranges comparison so I'll just ignore her senseless babble."

    Your confusing Applications programmimg with systems programming.

    Basically, you haven't said much ....at alll. I feel sorry for you Adam. You don't know much. Another way of saying it is you've basically said nothing in this thread.

    I know alot about programming. You've shown nothing more than a collection of general euphemisms.

    Renee

    Saturday, June 19, 2010 3:58 PM
  • Renee - Adam going to just ____ stop it the pair of you. Be professional and just stay off each others posts. It's everyone else who's losing out. Adam you messed up quite an important thread last time, the FileScan one, Renee your going to ruin this one. I'm ____ sick of it, your both as bad as each other. I don't give a ____ what the reasons where/are; just do the decent thing the pair of you and just stay away from each others posts; please. For ____ sake it feels like I'm giving a couple of kids into trouble, lets have a bit of professionalism.
    Saturday, June 19, 2010 4:16 PM
  • Derek,

    Again. I agree with you in specific circumstances yes. I could also provide instances where clean code would be more important than bug free code. In fact, most software sweatshops practice clean code over bug free code which is why I'll never work for one. Again both can coexist. That is the optimal goal.

    As far as my signature, well, I wouldn't buy a jackhammer if there was no concrete on my property.

    -Adam

     


    Don't bother learning something you'll never use.
    Sunday, June 20, 2010 5:09 AM
  • Again. I agree with you in specific circumstances yes. I could also provide instances where clean code would be more important than bug free code. In fact, most software sweatshops practice clean code over bug free code which is why I'll never work for one. Again both can coexist. That is the optimal goal.

    As far as my signature, well, I wouldn't buy a jackhammer if there was no concrete on my property.

    -Adam

     


    Don't bother learning something you'll never use.

    Hi Adam, you see I learned about functional programming F# just to see what it was about, no intention of using it, and I learned some simple techniques that lent themselves nicely to writing better multi-threaded applications. I tend to learn something and then see if it can be used... and I don't mean using technology just for the sake of using it {5 design patterns in 20 lines of code}... I mean learning what's out there and working out if and when they can be applied... it's part of my job... R&D... blue sky thinking. Example: Programmers Dvorak keyboard layout, learned that just to see and its much better than QUERTY. There might be no concrete but I still want to know how a jackhammer works encase the same technology can be applied to break up all the other materials that are lying about.  Anyway horses for courses... happy coding.
    Monday, June 21, 2010 11:23 PM