The Standalone Programmer: Innovative Software Development

Sometimes rules interfere with talent, skills and experience when innovation is needed

Introduction

Have you ever noticed that sometimes a single programmer (or very small team) can accomplish more than a large team? Sometimes it seems that large teams are totally unable to meet deadlines or when they do, they deliver mediocre code. Why is this? I believe that the reason for this is that software development is very different from most other jobs within most companies and most companies do not recognize this. Companies have become very good at mass producing everything from textiles to jet aircraft. The obvious thing to do is to create an assembly line and place people (workers) at various strategically chosen places on that line. Each worker is responsible for a specific task and quickly masters whatever that task is. This mentality has proven problematic in fields where innovation and talent are key. Consider innovative work like designing and building the space shuttle, missions to mars, building more efficient fuel sources, etc. In any of these fields, you will find cost overruns, missed schedules, and all the problems that are found in software development. Why? Because these fields require innovation, not automation. It is not about mass producing something, it is about inventing something totally new.

Let's face it, software development is about more than following rules, knowing the syntax of a language, following a development methodology or anything else. Software development can be amazingly simple or incredibly difficult. The only thing that can set a standalone programmer apart from the rest of the development community is his or her ingenuity, raw talent and experience (and in the absence of either, really bad management.) Leveraging that ingenuity can sometimes seem impossible because of the responsibilities we have on our job, and the constraints placed on us by ourselves and others. These responsibilities and constraints stifle innovation and can prevent break through ideas from seeing the light of day.

At some point, every one of us will be faced with a project or problem which when analyzed systematically appears to be unachievable, prohibitively time consuming, expensive, or complicated. At this point we often turn to off-the-shelf solutions to try and solve the problem or decide that we need to hire more programmers. While this may be the best possible approach, it is often a mistake to jump to this conclusion without first "getting away from the problem" and "thinking outside the box". The time has come to put that ingenuity, talent and experience to work.

The problem with education

There is a fatal flaw in the way people are taught to "program" in college courses and the software press. The same approach to software development is applied to every problem. Sure, there are different development methodologies, languages, tools, etc, but tools, languages and methodologies are not enough. Education simply cannot create talent where there is none. The idea that you can teach people to think outside the box and innovate on their own, while an admirable goal, is just not realistic. What education can do is expose talented people to new ways of doing things and provide a level of experience (though usually quite limited) that can provide a spring board for future success.

For some reason, many businesses fail to understand this and continue to place too much importance on college degrees, certifications, etc. If you read any business-oriented IT magazine or website, you will be inundated by reports of failed projects, statistics on cost overruns, missed schedules, etc. Companies are continuing to apply the same criteria to IT that they have for years, yet they expect different results. To me, this is ludicrous. The "if at first you don't succeed, try, try again" motto is being applied blindly without considering past performance and searching for better ways.

What needs to be done? If I knew the answer I would probably be sitting in Hawaii right now instead of Winston Salem, NC.

There is a flip-side to this problem, too. Many talented software developers devalue education to their own detriment. I do not have a college degree and this is something I regret all too often. If I could go back to when I was 18 and single, I would take the time to acquire a degree. There was a time when I said that I could learn anything I needed to without going through formal education. This may be true, but it would probably be much (much) easier to learn some things in a formal environment. My advice to those of you who are currently enrolled in a formal CS program and considering quitting, is to stick it out and learn as much as possible as you can.

Breaking the rules

I doubt that Shawn Fanning spent much time performing unit tests, usability studies or performing code reviews when he developed the first version of Napster. Maybe he did, but I seriously doubt it. To me, his story is one of innovative software development. He had a good idea and a commitment to seeing his idea brought to completion. I also doubt that Bill Gates and Paul Allen wrote a detailed design document before writing BASIC. They had an idea and free time and created something totally new.

These stories are not typical, but they are well known examples of something that happens every day on a smaller level. With every new project or problem, there is opportunity for innovation. Each situation requires that software developers use their talent and experience to evaluate the problem and design and develop an appropriate solution. A systematic process of design and review is always needed and should never be omitted. However, sometimes there is a nagging little voice that says "there's a better way to do this". When you hear this voice, stop and listen to it. Take a different perspective, try different things on a small-scale, scour the web, and don't give up until that little voice is satisfied. You may discover an approach you had not considered before.

Now you have a problem. How can you properly design something that is just an idea? Should you jump in and start slinging code, or should you be systematic and mentally test every eventuality, review every issue and write up your results? I am going to go against conventional wisdom, and say jump in and start coding. Start up that IDE and put that talent and skill to work and don't stop coding until your idea is vindicated or decimated. Don't look up, don't go to lunch, don't do anything that distracts you from the idea.

Some CS major or professor out there is screaming at the top of their lungs right now, saying "DON'T LISTEN TO THIS GUY!". Don't ignore all the screaming, but think of it as a control valve. There are always 2 extremes to anything. You can go overboard by doing too much or too little. All those rules and guidelines are there for a reason. They can and do work for most things. Don't read this article and use it as an excuse for ignoring the rules and guidelines all the time. I am not writing an "opposing view", but an additional view which can be combined with the rules to achieve greater success.

Rules to break and rules to keep

OK, so you have an idea, you have the IDE up and running and you are just about ready to start banging on the keyboard. Jump to it. While you are slinging all that code, here are a few tips to remember which can make you more productive and help keep your idea (if vindicated) viable.

Don't forget code quality guidelines such as initializing variables, code style, etc. These basic guidelines don't take any time if they are already habit anyway. Why, you may ask? Simple, you are going to have to test the code you have written and if it works, don't kid yourself, some of that code will find its way into production.

Be realistic. Rome wasn't built in a day.

Be unrealistic. Contradictive, isn't it? Think "outside the box", nothing is impossible. Rome wasn't built in a day, but maybe if your innovation existed, it would have been.

Don't forget comments. Your brain is converting thoughts into code. All to often when working without a plan, the thoughts only flow one way. You will write a function, class or something and the next time you look at it, not remember anything about it. I think of comments as code anyway, so commenting is just part of the coding process.

Keep your issue tracking software up-and-running while you code. (You do have an issue database don't you?) Use that issue database to keep track of the ideas that you have. If you don't have an issue database, then create a comments.h file and keep your ideas in there.

Don't worry too much about the structure of your code. You will probably write a function which should be broken up into several or a class which will need renamed, or rebased. Don't worry about these details much. What you want to achieve here is not perfect code, but to vindicate your idea.

Don't watch the clock.

Knowing when to stop

The goal of innovative development is not to build the world, but to determine whether your idea has merit and is feasible. Be prepared to find out that your idea won't work. Be prepared to toss your days work in the trash and never look at it again. So, at what point do you stop trying and go back to the systematic approach?

When you hit a roadblock, which seems insurmountable, STOP. Stop coding, stop working, stop looking at the code, stop thinking about the code, shut down the IDE and get away from the problem. Your idea is not dead, but you have to solve this problem before continuing. Why stop coding? Because your current mindset is to solve the problem through code and that is not what you want to do. You want to solve the problem with your brain. Your first thought will be to skip this problem and come back to it. This is very dangerous, because you will forget about the problem, or worse, solve the other 99 problems and leave this one insurmountable one behind. All the work on the other 99 issues, while not a total loss, will probably be a waste of time because you won't be able to use that work anyway.

When you reach a stopping point, evaluate where you are, what you have achieved and what remains to be done. Sometimes we programmers pretend that things are easier than they actually are. So, be fair and use your best judgment to gauge your progress. There is no magic formula, but experience will make this easier and hopefully more realistic. I have found that taking a lunch or dinner break alone and self-evaluating the work is very effective. I often come up with new ideas or realize something I missed.

How much time you spend in this innovative development cycle is also guided by experience and self-evaluation. You may spend minutes, hours, days or even weeks working like this. My advice to young programmers is to keep these sessions relatively short and never more than a day. There is a great deal that can be learned from many one or two hour sessions that is often not possible from longer sessions. Use these shorter sessions as learning experiences and opportunities to experiment while limiting your risk. The bottom line is recognize your own limits. Push yourself, but be conscious of your own abilities, experience and talent.

On the flip-side, you may discover that your idea works out perfectly. When you reach this conclusion, STOP. Stop coding, stop looking at the code, stop compiling the code, close the IDE. Why? Because you have achieved the goal of innovative development. You have solved your problem, vindicated your idea and are ready to leverage that idea for your needs. I strongly recommend that the first thing you do at this point is to write down what you did and how you did it in Word or notepad or something. Be as detailed as possible and try to cover all the important topics.

Two heads are better than one

I have found that bouncing my ideas off of a coworker is an excellent way to flush out the good ideas and filter out the bad ones. I am blessed with a boss who is an ex-programmer with excellent technical skills and knowledge. It is not uncommon for me to walk into his office and throw out some crazy idea I have had. Sometimes we will sit and discuss the idea for a long time before reaching a conclusion that it is infeasible or problematic. Sometimes he will say (in kinder words), that my idea is stupid. These brain-storming sessions often result in more ideas coming out because both of us are working on the problem together. Often, the original idea I had is proven feasible, but an even better solution is found, and sometimes, we determine that the original idea was sound and feasible.

One of the keys to this part of innovative software development is that the lines of communication must be open and egos have to be set aside. You may find that whoever you are working with knows something you did not or has encountered the problem before, or simply has some insight that you overlooked. You must not be protective of your ideas to a fault and you must be willing to accept that his/her ideas are better than your own.

I would advise every young programmer to seek out a mentor who can help you by providing support, experience and his/her own unique perspective. A mentor need not be a programmer, though it may help. Look for someone you can trust and feel comfortable talking to. Make sure that you are comfortable enough to have your ideas discredited. Your mentor must also be someone who can set his/her ego aside and see the big picture.

Having someone to bounce ideas off of and mentor you is a wonderful asset that can be priceless. You will eventually encounter a problem that is beyond your experience or skills, but having someone to talk to can help you to expand your experience and skills with fewer headaches and set backs.

Some of you may be thinking that this goes against the grain of the standalone programmer. I disagree. I am not saying that this other person will do your job, I am just stating that you will be a better developer if you can expose yourself to other peoples ideas and concepts. You will also find that you will make fewer mistakes in the long run.

There is nothing new under the sun

So, you have vindicated your idea and know exactly how to make use of it. When I reach this point, I think it is a good idea to bring up my trusty web browser and head straight to google. You may find that someone else has already encountered the same problem and come up with the same solution. Some of you may say that this is something that you should do before you jumped into the code. In this case, I believe they would be wrong. By allowing yourself to experiment and completely flush out all the issues, you are better able to review existing options and know what things to look for. You are much more likely to see problems in their design or implementation and be ready to ask probing questions (when possible) to their sales people/engineers/coders. You may find that an existing solution completely meets your needs and does exactly what you want it to. It may be a better business decision to use this existing solution than to take your idea and turn it into a production solution.

You can also use this as an opportunity to flush out any problems or issues you may have overlooked. When reviewing existing solutions, compare the details of the implementation and design to your own. Is there something they deal with that your solution does not? Be thorough in your review. The whole reason for taking this innovative approach was to solve a seemingly insurmountable problem. This is no small task and should never be underestimated. It is easy to overlook something and that is not what you want.

Even if you find an existing solution, you may still decide that you need to implement your own. Maybe the existing solution is too expensive, written in a language you are not familiar with, does not provide source code, etc. Maybe, you just think that you can do a better job. Innovate. Do the best thing you can based on your knowledge of the problem and solution.

What to do now

You have had an epiphany, tested and proven your ideas and determined that you need to develop a solution based on those ideas. Great! Remember those rules we have been ignoring, well it's time to pick that rule book out of the trash and turn to chapter 1. Requirements Analysis. That's right. You're not done yet and you can't just ignore those rules. However, having done all the fun stuff you just finished, you are better prepared to apply those rules. You will most likely be able to fly right through the process and jump right back into the coding because you are intimately familiar with the requirements and the solution. Don't skimp because there is always more to a project than just an idea and some code. You need that process to insure that you don't miss something, don't do too much and ultimately deliver high quality solutions.

All that code you wrote during your code slinging sessions may not need to be rewritten. If you followed good code quality guidelines, you may be able to refactor (OMG! I can't believe I just used that word.) that code into the production system. Don't be fooled into thinking that it is ready for prime time, because most of the time, it is not. The purpose for that code slinging was to let your talent flow into code, not into software. Know the difference and know how to take one and make the other.

Reality bytes

The idea of bypassing all that boring process stuff (design, requirements gathering, etc) to exercise your coding skills sounds wonderful, but most of us don't work in pure research environments. We work for companies which have real business needs and/or demands. You may be a freelancer in which case you still have to pay the bills by providing meaningful solutions to your clients. If your company has a well defined software process, you may have less flexibility in terms of choosing how you solve a problem. As a freelancer time is money and sometimes choosing a well trodden path is a much less risky choice than trying to do something new and innovative, and sometimes there just are not enough hours in the day.

Breaking away from the constraints of reality can be difficult. Even if you find a way to break the rules, you may not have an idea "ready to go" or you may think that your idea is too simple or has been done before. If you don't have an idea, think about the problems you or your users face on a regular basis. Take a look through the issue database (you thought I forgot, didn't you?). What about the project you are currently working on? Surely there is something that you can think of that needs improvement. Dwell on the subject for a while. Bounce a few ideas off a coworker, or ask a coworker for ideas.

It is likely that the idea you come up with will not seem like a tremendous achievement. So what! It is your idea and who cares if someone has done it before. You know you can do a better job that everyone else, or at least a better job than those around you. Skip a lunch, do whatever it takes, but find some time to try your idea out. If you feel the need to research the idea a little, do that too, but don't let yourself get distracted. Maybe you just can't find time to try it out. Write it down, then. Write as much as you can because if you don't, you will forget.

Once you have proven your idea, you may need to find a way to get it used in your companies product. You will need to prove your idea to your manager, team leader, boss, client or whatever. Keep this in mind while you are slinging all that code. Don't forget that for your idea to see the light of day, no matter how good it is, you will have to sell it to someone. What makes that person tick? How can you sell your idea? Will it make the product development go quicker? Will it reduce the cost? Will it increase sales? (If so, how?). Will it help them get a promotion or raise? Don't forget the impact it will have on you either. How can your idea advance your career, help you get a raise or whatever it is you want?

Hard lessons learned

Before I drop the subject of innovative software development, I want to instill in you the fact that sometimes the results are not as good as you thought they would be. To illustrate this, I am going to discuss one of my own failed projects. (NOTE: Although I was the sole programmer for this project, my boss and I worked together to design this project.) Unfortunately, reality bit me because I failed to solve 100% of the problems with my little innovation. A couple years ago, I had a client (while working for a previous employer) that needed a very in-depth database application. This particular client is a non-profit organization which provides various services to early childhood educators and day care workers. The goal of these services was to improve the quality of childcare by improving the quality of the workforce involved in childcare. The purpose of the application was to track all of the activities that the organization had with regards to the early childcare workforce and track the progress of individual work force members, as well as the workforce as a whole, over time.

I can't begin to explain every detail of the system, but here are a few details. Within the organization, there were several different departments which each provided a different set of services. Each of these departments collected various pieces of information from the workforce (often the exact same data collected by other departments), and performed different tasks. Some departments held workshops, others provided financial assistance, some provided in-class training or observation, some did testing, The application required that all interaction with workforce members be entered into the database. It also required that all data collection efforts be handled through the database so that there was a complete record of all activities. Every user needed a different user interface to accomplish his/her task because they were largely different. On the back end, the status of workforce members had to be tracked over time and reported on in many different ways.

At first, the task seemed insurmountable. How to provide different UIs to many different users, with different features and goals, while utilizing the same back end database and capturing a common set of data points? This problem and many more were overcome through a process of innovative development and practical development process. The end product provided separate UIs, shared the database, unified the data collection efforts, reduced confusion, and provided meaningful and in-depth reporting on the progress of change and improvement within the workforce. There were quite a few bumps and problems the first year gaining user acceptance and working out the kinks, but it seemed that everything was going well.

That didn't last long. Way back in the early stages of development, I had to come up with a way to unify the database on the back end while providing completely different UI's and features on the front end. This was just one of many problems that were overcome, but this is the one that ultimately doomed the project. The solution I came up with was extremely flexible and made it possible to store just about any thing that might be needed and merge that information with the appropriate workforce data. I knew of only one problem with the solution, and it became a critical flaw. The solution made it easy to get data into the database, and facilitated back-end historical reporting, but front-end day-to-day reporting was just not easy and just about required an advanced degree in SQL and a magic wand. I was aware of this problem and I even developed a half-ass solution to it, knowing full well that it was not a 100% solution.

The result was a system which met all of the customer requirements for historical tracking, multiple user interfaces, unified database, and much more, but lacked one critical component. Front-end user reporting was a royal pain and was often just not possible without going through many convoluted steps which only I was really able to do. As of today, this project is not completely a failure, but is headed down that ravine rather quickly.

The reason for sharing this little story is to stress the importance of solving ALL, 100% of the problems with your innovative solutions, because the client needs a 100% solution, not a 99% one.

Conclusions

Sometimes all the "proper" development methodologies and rules interfere with real advancements and innovations. As a standalone developer, it is important to recognize this fact and know when to break with tradition and exercise your talent and skills. It is just as important to realize that the rules and methodologies can have a tremendous impact on software quality. Leveraging both techniques will make you a better developer and may just make you the next Bill Gates.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

Good article: you make many cogent points which are well taken. However, most people appear to have have latched on to the education issue as being of major importance.

To my mind an education can only take you so far: it should not be seen as the be-all and end-all as it does not, of itself, endow the recipient with any special powers or skills. It may give an inexperienced mind a structure and discipline that it would not have learnt on its own but what if you already have that and are more than capable of learning what is required without need to resort to a formalised structure of learning? Does this path make you less intelligent, less capapable, less skilled? Does it mean you are less capable of overcoming an intellectual challenge? Of course it doesn't.

I have recruited many people over many years in this and other industries and have found that there are as many idiots with a degree as there are without one. Having a degree does not, of itself, make you reliable, hard working, flexible and innovative or give you any of the myriad skills needed to compete in todays workplace. And to say that you'd only hire those with a degree is inflexible and stupid. I'd fire you - you're quite obviously a 'business prevention officer' who cares more about certificates than someone's ability to do the job in a manner that befits the business.

I too never finished school and obtained my degree - but not because I'm unintelligent or unmotivated. I wished I had but other circumstances prevented finishing and eventually I reached that point where, when weighing the value of experience versus education - experience has become more important.
I worked with a pretty inexperienced college grad at my last company and the difference between us was black and white. While he has a college degree and I dont, he could only write in 1 language whereas I was skilled in 5. He had never done any web development, SQL, XML/XSLT or anything else for that matter. He was a VB6 programmer and not much else. He was also not familar with any methodology or framework so what exactly did they teach him in college?
Now I've moved closer to family and changed jobs but the scenario isn't much different. My team lead is a young college grad and this is the only job he as ever had. He is extremely smart and after 5 years with this company (including an internship) he knows our internal systems better than anybody else - but he lacks the breadth of experience from working with other companies and/or customers to know any better. He takes the approach of trying to reinvent the entire wheel with every system when perfectly good 3rd party solutions exist. This bogs down our development cycle to a point where we are lucky if we can meet any deadline at all. Also, not having well rounded experience has created a vacuum so he has no experience with "newer" technologies. He loaded VS.Net for the first time just about a month ago and is still fighting it.

I will take a person that has experience versus only a degree any time.

To value talent over learning misses the critical point that talent can rarely be exploited without training. Most skilled activities require talent and training and experience. The best practitioners in any field are most likely very talented but almost all have also had serious training.

I can't agree that it is best to try it yourself first before looking for ready-made solutions. This applies at all levels in a projects, from requirements capture through to how you write a sort routine. The talented but untrained developer who writes a bubblesort has no way of knowing the runtime implications and won't realise there are other sorts that may be better suited to her problem. I have worked on several 'fix it' projects where, typically, the application had gradually ground to a crawl as the volummne of data increased, only to find that the bottleneck was a naively written sort routine or was using cursors where a query when a query would have done. Obviously because the developer, college educated or not, hadn't ever been taught about sorting techniques or relational theory. The college educated developer would at least know that there are accepted solutions and that the choice of algorithm can be critical.

Another very common problem that shows up the difference between the trained and untrained is when new functionlaity needs to be added to an existing application. The talented untrained developer may have produced the original application on time and on budget but when the client request some apparently simple enhancement, it turns out the the database model or the code structure is such that the request can't be fulfilled without major reworking. The non-graduate has probably never heard of a paper entitled "GOTO considered harmful". Though it's no guarantee of good code, the graduate at least knows about the issue.

Reusablity, extendability, object-orientation, algorithms, db normalisation etc are all things you can learn without going to college but those who don't get it rammed down their throats at college are unlikely to appreciate their significance until its too late.

There was a time when software development wasn't taught at university. The system changed for good reasons. Sure, a college degree doesn't mean you will write good software but it will certainly make you write better software and it will prevent you making a lot of the mistakes previous generations have made.

When I graduated, I had no experience of ANY commercially used programming language such as C,C++,VB,Cobol. I wrote Prolog, LISP, ML. I knew nothing about the Windows API, office applications or ActiveX. I knew about event-driven programming, object-oriented programming, logic programming and functional. I knew nothing of SourceSafe, RationalRose, Visual Studio. I did know about algorithmic complexity, design methodologies and loop invariants.

When I graduated I didn't have the skills I needed start developing productively in a commercial setting. I thought college had almost been a waste of time. But I know now that what I learned at university pervades every line of code I write. I have come to appreciate the that the theoretical stuff of no apparent relevance to real-world development is actually critical to what I do every day.

Ten years of commercial experience have taught me that the theory will always be right while the APIs, the platforms and the tools change all the time. OLE became OLE2 became ActiveX became COM became COM+ and now you can forget it because we now have .Net assemblies. The concepts of Remote Procedure Call, interface based programming and polymophism where around before OLE and they are central to .Net . What I learned at college will serve me well all my professional life. My current knowldege of .Net, VB and ASP will be worthless in 10 years time.

If you want to be a developer, go to college, no matter how talented you are!

I am rather surprised at the number of people who appear to think that I devalue a formal education. I have re-read my article and I just do not see where this comes from. I think formal education is important and can be quite valuable (as I state in the article). I wish I had a formal education. I think I would have found many things easier to learn and I would certainly have been exposed to somethings long before I actually had to use them.

That said, I do value talent over education. Both are needed together, but give me an uneducated talented person any day over a non-talented educated one. A talented individual will be able to learn concepts at a much faster pace and will have a greater ability to apply his knowledge to gain experience. Education can shape a talented person into a well rounded programmer, but can rarely shape a non-talented programmer into a talented one.

You make some excellent and valid points. I agree that an uneducated programmer will often make mistakes that an educated one will not. (I know that I did.) Mistakes that can cost money and be problematic for years to come. In a perfect situation, a highly talented and well educated programmer is very desirable.

My main goal in stating that education was flawed was to point out one of your specific points: "When I graduated I didn't have the skills I needed start developing productively in a commercial setting." This is a terrible waste. As you say, you learned quite a bit and eventually became aware of the benefit of what you did learn. However, formal education could and should have taught you more applicaple things, exposed you to real-world requirements and real-world situations.

Though I am not college education, I have met many college graduates who appear to have been sheltered from any semblace of reaility by the education system. Instead of leaving 4 years (or more) of college with ready-to-use skills, they come out as raw "coders" with little usable skill. Eventually, with experience, they develop skills and the ones with talent truly excel. But what if they had been taught more relevant subject matter, been exposed to contemporary software development, and had usable experience during those 4 years. This was my point in the article.

monosodiumg wrote:If you want to be a developer, go to college, no matter how talented you are!

If college is an option, take it. If you are in college and can stay, stay. If not, your road may be rougher, but it is doable and you can excel. Learn the theory, learn the other languages, learn the concepts and methodologies. Invest time with relevant projects, relevant requirements, releveant needs. You will not only find a use for all the theory and concepts, but you will find things that theory and concepts can never teach you.

Matt Gullett wrote:...I do value talent over education.
Even an untalented developers can be taught to produce a properly constrained and normalised db model as that's there's a well defined process for doing so. That's arguably not the case when it comes to indexing choices, though a solid understanding of the underlying mechanis of relational databases will certainly help. There are areas where talent scores over training, graphical design for one. But in a technical arena like software development, these are the minority.

A talented individual will be able to learn concepts at a much faster pace and will have a greater ability to apply his knowledge to gain experience. Education can shape a talented person into a well rounded programmer, but can rarely shape a non-talented programmer into a talented one.

Can't argue with that.
My main goal in stating that education was flawed was to point out one of your specific points: "When I graduated I didn't have the skills I needed start developing productively in a commercial setting." This is a terrible waste.

It not a waste. It would have been a waste if I had learned how to work with OLE, SQL Server, VB and other then current commercial technologies. I don't want to have to do a new degree every 5 or 10 years because the tool manufacturers have changed they APIs, GUIs, etc. My point was that the college stuff helps me in everything and will continue to be of value for all of my working life. Immediately applicable stuff tends to be of only temporary value. Go to college to learn principles. Go to work to learn practice.

I should perhaps point out that the degree I did was heavy on theory relative to most CS degrees. Many graduates nowadays seem know some of the commercial stuff but are correspondigly weaker when it comes to the wider picture or the underlying principles. This may suit employers who want code slaves that can immediately be put to productive work but it pushes up the price for the fewer experts with a deeper understanding.

BTW, I learned ML at college (Edinburgh, Scotland where ML was invented). Microsoft have recently produced an ML for .Net implementation

As you say, you learned quite a bit and eventually became aware of the benefit of what you did learn. However, formal education could and should have taught you more applicaple things, exposed you to real-world requirements and real-world situations.

Ask a non-trained programmer to write a routine to sort an list of integers. In almost all cases the result will be what is known to a CS graduate as a "bubble sort". The graduate knows that bubble sort is O(n)=n^2 meaning the run-time is quadratic i.e. the runtime increase in proportion to the square of the number of elements to sort. He knows that when the list is 1000s or more items long, the run time will explode. He knows there are alternatives such as quicksort, which are slower for small lists but much much better for longer lists in fact O(n) = n*log(n) (log to base 2). That's pure theory. It's also 'real world' knowledge, true everywhere in the universe and for all time (assuming a Turing machine equivalent computer; quantum computers are a different issue.). I have fixed real-world programs that were running unnaceptably slow for precisely that reason.

I did a lot of pure logic at college. Theorem-proving techniques, propositional and predicate calculus. All very dry and theoretical. No apparent practical value. In relational databases, you will often see programmers using cursors. There are in fact very few occasions when this is the best course of action. You will find all the DB 'guru' types and even MS saying much the same thing. My knowledge of logic has, on several occasions, allowed me to rewrite these routines using a set theoretical approach i.e. using queries instead of cursors with a tremendous improvement in performance, a real world application of theory leading to a real-world benefit. Relational database systems like SQL Server, Oracle, Access etc are based on set theory. In fact most of the tools we use, languages, APIs, idioms, modeling techniques etc etc are based on years of theoretical research.
Though I am not college education, I have met many college graduates who appear to have been sheltered from any semblace of reaility by the education system.

;) LOL I'm a prime example!!! I didn't even know what a PC was when I graduated. I was fortunate enough to have been exposed only to Unix, usually running on sparcs, which was (and arguably still is) one of the the most advanced OSes around by miles. Multi-tasking? Roaming profiles? reflection? These are all features that have been taught in CS courses for 15 years or more.
Instead of leaving 4 years (or more) of college with ready-to-use skills, they come out as raw "coders" with little usable skill. Eventually, with experience, they develop skills and the ones with talent truly excel. But what if they had been taught more relevant subject matter, been exposed to contemporary software development, and had usable experience during those 4 years. This was my point in the article.

The learning curve for .Net for me is a lot shallower than for most non-college educated programmers: I already know what remoting and reflection are about. I only need to learn the .Net implementation of it. That is why I never go on courses where they spend 1/2 the time telling you what these things are about and why you might use them. The non-graduate VB whizz new to .Net will have a harder time.

monosodiumg wrote:
If you want to be a developer, go to college, no matter how talented you are!
If college is an option, take it. If you are in college and can stay, stay. If not, your road may be rougher, but it is doable and you can excel. Learn the theory, learn the other languages, learn the concepts and methodologies. Invest time with relevant projects, relevant requirements, releveant needs.

Without guidance, i.e. someone who can point you to the things that matter and explain their significance, how can the talented novice know what matters and what the important concepts are? this is the point of a college education. You're absolutely right that one can pick these things up as one goes along. College is the quick tour that gives you all the highlights, explains why they matter and points out things you would never have thought of. As they say here in Scotland: I'll take the high road and you'll take the low road and I'l get there before you

BTW, I have worked with graduates and non-graduates and my experience has led me to the policy of never using a non-gradute in a senior role e.g. as lead. The non-graduates I tend to use as grunt programmers, not out of any prejudice but because they usually don't have the necessary skills or knowledge to be effective architects or designers or project-managers.
You will not only find a use for all the theory and concepts, but you will find things that theory and concepts can never teach you.
Examples?

Thanks for the followup. I enjoy hearing opposing views (though we agree on many things).

monosodiumg wrote:Even an untalented developers can be taught to produce a properly constrained and normalised db model

This may be true, but I think it reveals a difference in the types of projects/clients we deal with. I am typically faced with poor or no specs and must design the spec myself. A standalone programmer rarely gets detailed specs that are accurate or meaningful. Education can and does help especially in the purely mechanical (probaly not the best word to use??) areas such as DB normalization of an existing DB design, but designing a new app from scratch along with a DB layout, indexes, etc is much more involved and requires at least somoe talent. Certainly education makes the job much easier for a talented person.

In reality, I don't think we disagree about much. I am not against college education, completely for it actually. I have just seen too many college graduates with a degree in CS who are completely untalented and have a difficult time thinking outside the box. It seems to me (from the outside looking in) that they are taught far to narrow a curriculum. Maybe this is (as you say) because the depth of the education has changes since you were in college. It may be that in the past theory was taught more and this is what is lacking in current curriculums. I still believe, though, that the current batch of graduates is lacking far more than they should.

If/When I hire a new programmer, I do not want or need a coder (code slinger, keyboard jockey, etc). I need a true developer who understands the theory, can use the tools and can get his feet wet immiedately. I simply do not want or have the time to hold his/her hand. Give me talent that can be harnessed, not education that needs constant direction.

I do agree with you that uneducated programmers often lack exposure and knowledge to important concepts, theory and methodologies, especially the standalone ones. This is partly why I write this series of articles, to express the obstacles I have faced, the lessons I have learned and to learn what others have to say. I have invested countless hours reading books on CS, concepts, algorithms, optimizations to try and round myself out. This is an important activity for the non-educated programmer, for precisely the reason you gave, it goes with you no matter what language or tool you use. I also agree that this is more easily learned (for most people) in a formal environment, instead of being self-taught.

monosodiumg wrote:Without guidance, i.e. someone who can point you to the things that matter and explain their significance, how can the talented novice know what matters and what the important concepts are? this is the point of a college education

Agreed, whole heartedly. For those without a college education, a mentor is very important. Preferably someone with a good portion of their career behing them who has worked in the trenches and has a passion for the industry.

monosodiumg wrote:BTW, I have worked with graduates and non-graduates and my experience has led me to the policy of never using a non-gradute in a senior role e.g. as lead. The non-graduates I tend to use as grunt programmers, not out of any prejudice but because they usually don't have the necessary skills or knowledge to be effective architects or designers or project-managers.

I can understand this perspective and it sounds like it comes from experience, so it is hard to argue with it.

monosodiumg wrote:Examples

Why KISS is so important.
Why prototyping can be dangerous and powerful at the same time.
How to design a spec and explain it to non-technical people.
When to optimize and when not to.
What to optimize. (ie. for memory, speed, concurrency)
Understanding the business need that drives software development.
Etc.

I enjoyed the article. This series has been great information for me. I am a graduate in CS with emphasis in math and I will have to say the criticism I have seen of Matt's position is nonsense. Bubblesort? I mean really. Many of the talented non-graduates I have met have read much more Knuth than I have. These talented people are out learning about programming, UML, etc as applied to the real world while CS majors are spinning their wheels for 2 semesters writing 7 different sorting algorithms. I think the idea that non-graduate programmers don't know about software architecting, design patterns, and database normalization is complete nonsense. I have found much more applicable theory and succinct coverage of these topics in technical books than in a semester's worth of glossing over bulletted lists. While on the topic of databases, I remember never implementing transactions or even covering cursors other than to discuss them theoretically, and then cursors were only mentioned in the context of being released at Commit/Rollback points.

These talented people are the ones burning the midnight oil researching and learning everything they can about programming theory and practice and these include the "hifalutin" business of design patterns and UML. These things are mostly given cursory studies in undergraduate level courses anyway.

What I often found in my classes was that the people being the most successful in terms of grades and so forth knew nothing about computing at all besides being able to write a Linked List implementation and spout mental xeroxes of database theory.

I value the education, in terms of being *prepared* for computer programming and theory, but I think there is a very large hole not being filled. I think this is why it appears that the overwelhming majority of CS majors do not go into a programming related fields. How can someone who has only spent time writing quadratic hash algorithm implementations write any sort of useful program? Well, this has been long and drawn out but for someone who has been there, and at a mildly prestigious college as well, it seems self-indulgent and banal to suggest that the graduate who wrote a Binomial Queue while copying it out of a textbook from the 1970's is going to be a much more productive software architect than one who spent her time voraciously studying all aspects of computing.

Even leaving programming aside, I don't know anyone from my graduating class who would have any idea what to do with a Cisco router or a sick domain controller. I don't think undergraduate CS is a waste but I think it has an identity crisis.

Maths.... In the world of mathematicians processors speeds are infinite and latencies are 0 I'd trust a maths graduate to design and implement an algorithm correctly but I wouldn't hold my breath waiting for the answer

Actually that's nonsense and I don't subscribe to it.

However, many real-life situations need some understanding of the logical fundamentals in that area, be it relational databases, image processing or whatever.

Our current project is reaplcing a system that works perfectly well except for one small component built by 3rd party contractors a few years ago . That component talks to a DB and has been slowing down steadily as the volume increases. It will soon be too slow to cope with the current data rate. We know what it does at the logical level and the algorithmic complexity of the task should be O(log(n)) (not something you'd learn on the job) but the degradation is linear (n is db size, not the data rate). Unfortunately we do not have the source or any way of getting it so what might have been a 5K fix is now a 500K replacement project. It would have cost next to nothing it it had been reviewed by a developer with a better understanding algorithm performance.

I do not know if the origianl developer(s) were graduates or not. Odds are they were so being a graduate is no guarantee of good code , not by a long way.

On the job or self-training is great and most of my value comes from such training but over the years (decades now) since I left college, I have come to appreciate that avoiding prolem such as the one we are resolving now is down primarily to the structured tour fo the CS field that I got at college. At the time I had the view that I will never use this stuff. NOw I know I was right for 70% of it but the other 30% for me make the difference between me being a code jockey and a pro.

As to critiscism of Matt's position, on review I find that the various positions by and large agre. I do not discount the value of self-teaching and Matt does not deny the value of a college education. We agree that neither is necessarily sufficient nor valueless.

You are aboslutely right about the hole. I question whether that hole needs to be filled by college education. I think that hole will be filled by the individual as she moves through different positions in the course of her carreer, in the same way that the first 4 year of a medical degree do not really prepare you for the realities of all the niche you might find yourself in 5 years later. I never will find out what the differnece between a router and a switch is but I will always make sure that decision is made by a network person.

I'm not ure what your point about cursors is. I can tell you that I strongly suspect our current problem to be cursor related. Fact is, an awful lot of programmers using DBs use cursors far more than they shoudl, be they graduates or not. A graduate who has done a DB module with a good theoretical component is far less likely to use a cursor when it isn't required.

The real differnece isn't between the self taught who are learning everything they can about programming theory and practice
and the graduates. The latter may in fact be more valuabele than the former but few people are such good autodidact and college is a fairly reliable way fo getting a good grounding. No, the real difference that concerns me is with the developers who have picked up most of their skills empirically. They may well be hyper-productive when it comes to coding and as such they are really valuable but for the enterprise environment in which I work, their output must be checked by someone with a theoretical understanding to avoid the kind of problem we are dealing with now. Your .Net whizz kid who's learned it all himself and blows you away with really neat app may not appreciate that the lighting fast code he has produced will blow up when you hit it with real life volumes of data.

The only thing I know about sorting Cisco router or domain controllers is to take them to the network support team. A neurologist with a sore belly will likely go to a general doctor even though he is a medical expert himself. CS is like engineering or medicine or law in that it is a wide field and no one will master all areas of it. That's not a symptom of an identity crisis but evidence of a mature discipline.

Let me clarify that I donot hold the opinion that a college degree is essential . It's very useful to me because, when I look atthe list of modules a candidate has taken, I get a quick guide to what I can expect that candidate to know. If I agree compltely that you can get capable and productive effort from non-graduate coders (that's said I have a special issue with the "conversion course" type of graduate who's only dev skill come from a 12 month postgrad MSc course).

Also, with over 30 years in the field, President/CEO of my own company, and a woman as well....I don't have a degree.

I intentionally DIDN'T get one. Way too much emphasis on that. Besides, a degree in this field now is useless, companies are outsourcing overseas, so no need to get one, there will be no jobs here eventually, lol. It absolutely amazes me what people say and what they do and how far apart the two things are sometimes.

You are also VERY right about the way companies treat our field.

As a consultant, I have had to go into many companies and 'rescue' projects and beat deadlines that were missed because too many people were on the project. MANY times I did it alone, replacing a crew of 4 or 5.

The traditional software engineering methods such as the sequential (waterfall) model have the following main steps: 1) Requirements Analysis, 2) Design, 3) Implementation (coding), 4) Testing, and 5) Support/Maintenance

Later models such as iterative evolutionary, and even up to RAD methodologies still use these same steps at their core.

What you are proposing is a form of 'extreme/prototyping' RAD. i.e. Although the developer does not realise it, he is indeed going through the Analysis and Design steps in his head; just not producing any documentation.

Unless you have an idea of the architecture and purpose of your application (i.e. the Analysis and Design), you can't proceed to the Implementation.

If the developer is not part of a team, or does not need to work to a pre-defined technical specification, or is going through a prototyping cycle, then there is no reason why your rapid RAD model shouldn't work.

However, as with all RAD approaches, the trick is knowing when to stop!

This theme mirrors what we know about psychology, where people are either left or right brain dominant. Left brain people are linear, logical, do well in school and in corporate environments. Right-brained people are more intuitive, improvisational, not as well-suited to an academnic environment, but capable of entrepreneurial and creative genius in the same fields where they might have done poorly in school.

The right-brain also likes to come up with solutions in a more iterative evolving manner, whereas the left brain likes to see the entire problem up front with the one right answer(think standardized tests).

Personally, I think that the trend towards .NET favors bringing the right-brain into software development. Freewheeling intuition which might have caused chaos in C or COM works great with C#.

JakeM wrote:Personally, I think that the trend towards .NET favors bringing the right-brain into software development. Freewheeling intuition which might have caused chaos in C or COM works great with C#.

This is an interesting point. I firmly believe in the importance of the adequate up-front problem analysis, requirements gatehering, etc. No language or tool will ever change this. How can you develop something which you don't remotely understand? However, when working with ASP.NET (or .NET in general), you are somewhat forced to a particular programming model which is more formal and controlled that what is inforced by C++ or C.

JakeM wrote:Freewheeling intuition which might have caused chaos in C or COM works great with C#.

Agreed provided sometimes in the future MS releases an invoke debugger. Sorry to tell you, but the CLR internals is full of WIN32 and COM plumbering, resulting only in additional behaviors/limitations to learn (on a pray-it-works basis).

Another great article, Matt. You bring up points I see in a lot of new software engineers. They seem to gather around two extremes. The first wants to always apply a certain methodology to every problem. These folks are very rigorous and eventually produce a result. The other extreme always 'wings' it, often producing results quickly. The problem with the first group is that they aren't very adaptable to changing requirements, don't produce innovative solutions, and take a loooong time to produce anything that works. The problem with the second group is that their solution, while it may fit the immediate problem, it's not extensible, it's usually not robust, and is rarely maintainable.

You approach is similar to one I use a lot. Hack together a working model or prototype, identify the primary issues and complications with the approach, then go back and build the real thing. Maybe you use code out of the prototype, maybe you don't. This method seems to combine the best of both worlds.

I agree. Too often, IT people fail to benefit from mixing methodologies, technologies, languages, etc, to achieve better results. I think this is partially because of the sheer complexity of the IT world. Many languages (VB, C++, C#, Java, ...), databases (MS Access, SQL Server, Oracle, ...), database SQl dilects, COM, DCOM, .NET, and hundreds more. It is easy to master any one of these, but learning to use all of them together can be quite difficult, and therein lies the real challenge. Overcoming the challenge is key to success and if that is accomplished by methodology X, Y, Z or all three combined, it really doesn't matter as long as the end result meetds the specifications and quality demands.

Great Article.. Lots of good points.. but Bill Gates and Paul Allen didn't write a detailed document plan of DOS because they didn't write it.. they purchased it and sold it to IBM as their own design.. well acctualy they sold an operating system to IBM, and then purchased DOS and said here ya go.

I disagree with many of his points. A college education does not count? Tell that to NASA software engineers building the next "innovative" process control system.

I've never dealt with an organization where the motto is "if at first you don't succeed, try, try again." No, its more "Get it right the first time!"

I've been in the computer industry and software programming for nearly 26 years now and I come to the conclusion that the "future is nothing more than history unlearned!" I believe an ex-president said that.

This article reads like someone wanting his boss to read so that he can allow him to play more on the computer.

Matt, while you are probably a great programmer, a college education does count. I won't hire an engineer without one and there are means reasons for that. A degree says a lot about a person. Not just about his "specific skills."

Where you work best, be it a Project vs Product development area, does depend on your R&D skills. Sure, anyone can be a "bright" person. A person can come up with ideas. But you need to be able to produce and market the product in order to be successful. There is a reason why "Marketing come before Technology."

One of the advancments in technology is the component engineering and smart interactive development environments. It is these technologies that has allow for more programmers (college educated or not) to be more productive.

However, in my opinion, it came with a double edge sword. The technology has merged the disciplines. So now you are everything under one hat and in my opinion, one part of the final product is of less quality. You can't be a lone wolf forever.

In any case, if you [speaking in general] are still young, full of energy and do have "Innovative software programming" skills, I do agree with one thing, Don't Waste Time! Go for it and do something with it because eventually it will get harder and harder for you. The industry is changing too fast to be a master of all things. Become an expert at "something" and make some bucks at it.

Thanks for the feedback. I always appreciate feedback because I try and learn from other people.

I am not sure how you came to the conclusion that I believe a college education does not count?? That is not my feeling at all. In fact, I think it does say alot about a person and that it is a valuable asset. I wish I had one, and maybe someday I will acquire one. As I said, a college education is a great thing for talented people because it exposes them to new ideas in an environment that often makes it easier to learn. I have met many talented and untalented people some with college degrees and some without. The college degree does seem to help round-out talented people, but without talent, it often seems wasted.

Also, when I used the phrase "try, try again", I was not saying this was a concious decision, I was just saying that I see companies experiencing failed projects, cost overruns, missses schedules, etc over and over again and I really don't see them changing their recruiting, hiring or training practices to make this better. Maybe you see things differently, if so, please tell me your experience because I would like to hear about it.

As far as playing more on the computer, sure any programmer might want this. However, in every point I made, I balanced the willy-nilly approach with the systematic, methodological approach that is always necessary in software development to achieve high quality results. I firmly believe in the importance and absolute necessity of the tried-and-ture methods and approachs. I also believe that sometimes ones talent and skills are constrained by the environment that often exists with these methods. Escaping these constraints, not for producing production code, but for experimenting with new ideas is important because it removes all constraints and allows the talent, skill and ingenuity to flow while protecting the quality of the final product.

Again, thanks for the feedback. I look forward to hearing back from you.

Been there, done that. All software craftmen start off with a passion. That is what makes difference from the rest.

You just never know what the lost opportunities are when you don't have a college education. It takes a rare individual to be successful without one.

Lets not confuse Software Programmer with Software Engineer. A Software Engineer does not really program he engineers the system and then passes it own to the programmer.

I'm a Chemical Engineer by degree. I learned over 21 different languages over dozens of platforms from micros to minis to mainframes to hybrids. I hardly doubt the would had the opportunity with corporations without a degee. I wouldn't have the resources. I've done work on many different technologies, process control, simulation, articifical intelligence and so on. Yet, I was one those guys who make an early mark in the early modem era. I too was one those guys where the boss would say, "You want it down tomorrow, give to bill. You want it done right, give it to hector."

After 11-12 years in corporate america, I went on my own with a successful shareware product. I got out of the shareware business in 97 and now have highly successful commercial product line. I can do the work of five people.

The point is, eventually, you got to grow up. It catches up to you. At some point the passion wears thin. You need to be productive and make a living. Of course, the odds are you will get married and begin to raise a family.

And Of course, I don't speak for all. There are always a new champion and many will have a different perspective.

So its ok to disagee. I'm not john ashcroft. You will not go to jail But an college education does count in my book. Sure, with experience (in time) you can make up for it. But like I said, you have to be extra special and rare to be very successful early on and to get your foot in the door. Look at it this way, on average you will command a better salary.

For one thing, engineering was more challenging for me and I was already far ahead than most with "computers" back in 1977 when I started college. My expertise became "Applied Engineering with Computers" and very few was as good at it as I was. That is why it open so many doors for me. I never regretted getting the complex training of a chemical engineering degee.

Second, I didn't say you have to have a degree for the field that you are in. Most people do not believe it or not. It is the having the degree behind you that says alot about the person. This is akin to just having a "high school diploma" or "GED" just to a get a basic job in many places. In my view, a person who has shown to have the capability to go to college, finish it successful, adds a trememdous value to their resume. College is not just about the specific field you take, but about how to solve problems, how to do to research, how to communicate with others, etc, etc, etc. Does that mean that you get a "Liberal Arts" degree and then expect to get a job as a Software Developer? Probably not, you still need to show you have the capabilities. But indicating you do have the degree will look much better in the eyes of the recruiter. Trust me.

Actually he didn't mention DOS but BASIC and no I doubt that they wrote a design paln for it since it was invented years before (1963 to be exact) they implemented it. They did not create anything new at all. As to your dig at C# (which has nothing to do with this article) you obviously don't know much about it or it's creation or goals.

With the current layoff climate, I would not suggest developers to fully comment their code or make it self descriptive. I know this sounds childish (and opposite to your article), but how else do you protect your job ?

The best way to protect your job is to ensure that your company recognizes the value that you provide to them and that it is in their interests to keep you around. Not 100% reliable but surely preferable to deliberately doing a second-rate job.

You should save yourself and your company years of grief by shooting yourself through the head immediately. Believe me, in the long run it'll turn out better for everyone. - Tyto (at arstechnica)

Today's CTOs and decision makers wrongly regard software programs as the result of mechanized and totally formalized design processes, exactly as if when you start a development, you know exactly where you'll be two months ahead.
Unfortunately, we are talking IT here, which is both an intellectual activity and full of "unproven" rules and techniques. We are not talking about the design of a car, for instance.

Signs of a software company being wrong:
- visibility under a day or two.
- everything managed as emergencies. When everything is top priority, how do you evaluate priority?
- fuzzy business model, which tends to make you produce lousy code aimed to sell in more than one niche market with the side effect of doing nothing really good, instead of a single well defined market where a product can be well designed for.
- R&D department not doing research at all. In France, a company with R&D staff has reduction and advantages on taxes, thus it's part of the public company claims to have strong R&D. Know what I mean?

The educated guy knows that the short visibility is only a consequence of purposed and targeted employeee management which in short is to let you know only what you are expected to know (virtually nothing in practice). Only to make sure you are loyal to the company. In practice, this makes your job full of unnecessary stress and wonderings.

Taka Muraoka wrote:The best way to protect your job is to ensure that your company recognizes the value that you provide to them and that it is in their interests to keep you around

Lately at my company, I have seen core programmers of a suite been layoffed.
The only ways a company recognize your value are :
- ability to have your share in the decision process
- a lot of paid training (and free bananas of course )
- be able to capitalize on the company core value, rather than go in all directions at the same time ("try everything, do nothing good").
- demonstrated will to build appropriately dimensioned teams of workers (QA+dev+...), instead of one-fits-all.

Again, the only way I know to manage job protection is to produce code that you are the only one to understand and control. I know that's a lame perspective, but the software industry is a lame system, and the only way to fit is to enforce that system.

A few years ago, I was naive enough and yes, I sometimes thought things like what you say. But now that I know the entire software industry is rotten to death : we eventually will get outsourced, I am now only making sure I get my month income. I am helping my pals build relationships and breath some air out of the current CTO self-promotion-projects. Period.

Your attitude is both unethical and unprofessional. If I were your employer, and I suspected you of this behavior, your name would go to the top of the layoff list, regardless of your supposed skills. Employers retain valuable employees, not the ones that attempt to extort them.

[Edit]I am looking forward to knowing your definition of extorsion !? Your company asks you to release product A with feature X,Y,Z due 2 months ahead. You manage to do so, the product is released. You have been doing what you are paid for. Where is the extorsion ?[/Edit]

Well - that little code that you made before your project manager sees your bad coding style, warns you, and some weeks later fires you can easily be replaced. And skilled replacement it there. This is not '98, as you said!

Out of those 50%, only a fraction could figure out anything that might be purposedly implemented to remain under one's control.

When you have a few hundred thousands lines of code, it's not even a question.

Things I would agree with you is that it's much beyond technical points, but I am afraid you are talking technical things here. Intern political points far outweigh technical points, and that's actually my point.

jhwurmbach wrote:And skilled replacement it there

No. Rejection rate is very high : one possible candidate out of 100 resumes or so.
In addition, finding a person out there who would accept to maintain 16 bit code is hard...

Well, where I work almost all of them are. Product managers are marketing, project managers are simply the foremen of the team.

.S.Rod. wrote:could figure out anything that might be purposedly implemented to remain under one's control
Maybe we work in totally differnet environments. What you talk here makes absolutly no sense where I am working. You are in a team here.

I am really not sure how to respond to this comment. Obviously, others have already chimed in and I have to say that this sounds unprofessional. Also, I would state that this might work IF and only IF, there is a lot of code like this (ie. more than a few 1000 lines) and the code represented a major portion of a critical business app (ie. internal-mission critical, profitable product, etc). Even if this method does provide some short-term job protection, it is highly depdentent on the success of the software using the code. Also, as far as career-security, this method might pose a problem because your current employer will be less likely to give you a good report. From what I can tell, IT careers are littered with many 1-4 year jobs, not one 30 year job.

Besides all that, do you enjoy working like this, or do you just feel that it is necessary in todays climate? I ask, because I know I would not want to support my own code if it were written this way. I maintain several hundrend thousand lines of code and if not for comments and standard naming conventions, etc, I can't imagine how I would maintain it. I can't remember the nuiances of some of the various parts of my applications. The comments are there to help me, and as a side effect, will help others too.

I appreciate the feedback, even if I do disagree, because it shows me an opposing view. I would like to hear some more support for it, though.

Matt Gullett wrote:IF and only IF, there is a lot of code like this (ie. more than a few 1000 lines) and the code represented a major portion of a critical business app (ie. internal-mission critical, profitable product, etc).

Yes, both.

Matt Gullett wrote:your current employer will be less likely to give you a good report

Reporting is for naive people. It's my experience that whether or not you say hello in the morning to your pals (and even how you say hello) impacts much more how your quarter reporting tells you are a high performer, or almost a moron. I have worked at both large and small software companies. I don't know if this has anything to do with the culture on overseas (american managers look a lot on the surface, rather than what is your value).

Matt Gullett wrote:I maintain several hundrend thousand lines of code and if not for comments and standard naming conventions, etc, I can't imagine how I would maintain it.

You get easier used to your own crap, than others.

Matt Gullett wrote:The comments are there to help me, and as a side effect, will help others too.

Irrelevant when you have one/two developers.

I have worked in several companies where it's obvious that what managers want from you is to both produce the code they think of (and can't manage to produce the specs for, that's another story in itself), while at the same time be entirely self-describing when you hit the check-in button : this requirement is not signed and the contract and, as a result, only tends to show that what managers want is you out of the product you release, just to make sure you have been right and properly instrumented (read : screwed).

I can only imagine that he writes very small programs and not very often, unlike most professional developers here. Not commenting my code would make my life 100's of times harder for me - so what's the point. No comments is bad coding style and it would soon be picked up by peer reviews or anyone who happens to be looking at my code.

As for not commenting code as a method of job preservation - this argument does make not sense. You intend to keep your job by writing sub-standard source code? Good luck mate... and the same to whatever tin-pot organisation you work for.

Not that much. To rephrase the article subtitle "...rules sometimes interfere with innovative software development", I guess yes even if we are not exactly talking about the same kind of rules : french audience[^]. (offshore in french consulting/services companies).

GREAT ARTICLE! The author is someone with a brain so he should be careful about posting on this site!
Stick your comment about "unprofessional" up your professional rear end!
You represent the stagnant mentality of all too many programmers and that is why you kiss the rear ends of employers like me!