Software Development

Developer efficiency myths and truths

There are tons of products on the market that claim to improve developer efficiency, from different languages to IDEs, automated build tools to automated build environments. Justin James tries to bust some myths, bring to light a few truths, and show some partial truths regarding developer efficiency.

If you read the ads in development-related magazines or on Web sites, you would think that solving development inefficiency is a great path to making big bucks -- and I believe that it is. There are tons of products on the market that claim to improve developer efficiency, from different languages to IDEs, automated build tools to automated build environments. I will try to bust some myths, bring to light a few truths, and show some partial truths regarding developer efficiency.

Myths about what leads to developer efficiency

#1: Drag 'n Drop IDEs are the be-all and end-all.

Drag 'n Drop IDEs are great... for building UIs. Outside of using a Drag 'n Drop IDE as a graphical code generator for UI-specific tasks, they universally stink. Unless you are writing an application so basic that the IDE's assumptions about how code should be written won't hurt things, chances are you will rip out at least half of the code that the Drag 'n Drop IDE put there for you. Go ahead, use Visual Studio or Eclipse -- they are great IDEs. But be wary of trying to drag ‘n drop your way to a complete application.

#2: Slumber parties at the office equal more quality work completed.

I call a workaholic programmer who regularly pulls all-nighters The Martyr. It is tempting to think that putting in more hours equals more work, but most developers are spun out by 5:00 PM. Development is brain-taxing work, and you cannot do it when you're tired or improperly nourished. A late night here and there may pay off, but chances are, the quality of the work done past 6:00 PM or 7:00 PM is low, and the next day your efficiency will be in the toilet. Avoid the late night work whenever possible -- you are not nearly as efficient as you'd like to think.

#3: Caffeine, nicotine, and sugar are your friends.

Caffeine, cigarettes, and sugary beverages contain chemicals that might provide a temporary boost in awareness, alertness, and concentration. But the 30-minute jolt that a can of Mountain Dew might give you is followed by a much longer crash that dulls your senses and fatigues your body. This is why you see people with trash cans full of soda bottles, cigarette packs, and coffee cups; they need to continually ingest the chemical(s) of their choice to find a balance. Trust me, I have been there myself (regrettably, I started drinking coffee again a month ago, but I am still cigarette and sugar free). Try to replace the coffee with water, the sugar with fruit, and find a way to quit smoking. Not only will you stop feeling the nasty side effects of coming down, but you will also have much fewer interruptions when you do not need to leave your desk constantly.

Truths about what leads to developer efficiency

#1: Environment matters

No, I am not talking about Al Gore or Greenpeace. If you are in an office, I bet good money that there is a standard fluorescent light bulb over your head. It probably cost the builder $45 or less to install; meanwhile, full-spectrum task lights can easily cost over $100.

Ever notice how many IT pros turn the lights out in the office? It is because fluorescent lights are horrible on your eyes when you're using a PC; turning the lights off reduces the immediate stress on your eyes that causes the 2:00 PM headache. The problem is that your eyes dilate even more when you turn the lights off, letting even more of the eyeball killing monitor light damage them. In other words, the short term "fix" does long term damage. Go ahead, buy the $100 task lamp; it is cheaper than a new pair of glasses or contacts, and it will improve your efficiency significantly since you won't be in pain by mid-afternoon.

#2: Practice makes perfect

A lot of developers think that warming a chair for 10 years makes them a better programmer. The fact is that someone who spends time reading about new ideas and trying them out on their own time is going to learn valuable lessons that they can apply in their day-to-day work. If you want to become more efficient, I suggest spending time working on a project (at home or set aside an hour or two a week at the office) that is related to work but that uses techniques that are new to you. You will discover that learning new techniques always pays a huge dividend.

#3: Limit interruptions

Your manager is making you less efficient. Every time he or she stops at your desk for a quick status update or e-mails you a memo reminding the team of the dress code policy, your concentration is broken. Even a slight distraction of a minute or two can take many more minutes to recover from and get back in "the zone." Add that up over the course of a day, and you could be losing up to an hour's worth of time where you are fully "in the problem" due to your manager or a coworker interrupting your thought process.

Close the door (if you have one), put blinders on so people near you don't bother you, and close your e-mail and IM clients. Limit opening your communications software to a few times a day (after a meal, a restroom break, or other similar time is perfect, since you have already lost your train of thought anyway). If it is really important, they can pick up the phone and call you.

Partial truths about what leads to developer efficiency

#1: Code generators may lead to more work on your end.

If you are doing a ton of rote tasks, like creating the accessors for a class that represents a 200 element XML schema, code generators are great. Drag 'n Drop IDEs make short work of generating UI code, but unless your task is extremely generic, you will probably spend more time tweaking the generated code than it would have taken you to just write it yourself. For specialized tasks, sometimes a text editor that supports regex find/replace or a spreadsheet program like Excel can do a task in a few moments where pricey code generators fall flat.

#2: Language matters some of the time.

Sometimes language matters, and sometimes it doesn't -- it is completely situational. For example, many of the languages that can be written extremely quickly thanks to type inference or syntactic tricks are often difficult to follow when they are maintained. The two minutes worth of typing saved can cause an hour of wasted time down the road. The current mainstream languages (Java, VB.NET, and C#) are all so similar (VB.NET is slightly more verbose) that none of them are particularly more efficient to work with. Some languages do have unique properties and advantages that can significantly impact development time. For instance, try writing something that is as pure logic (or math) as a weather forecasting system in C#, and you'll be sorry. On the flip side, a typical Windows desktop application written in Fortran will probably take forever. Library support matters too; some languages, despite being weaker, in and of themselves, have library support that makes up for it.

#3: Personal life

Developers who get phone calls from friends and family for a total of two hours a day are probably not going to get much done. However, locking people down is not going to fix the issue of personal calls either. For many people (particularly those with children), a five minute phone call might save a trip home. In an ideal world, developers would not let their personal life and issues affect their work. In the real world, an argument with a spouse, money worries, the kids' grades, and so on can and will spillover into someone's work time.

So, for all you managers out there, while personal telephone calls represent an obvious inefficiency, it's fairly useless to have a programmer in the office who has something heavy on his or her mind. They won't be able to concentrate anyway, so go ahead and let them do what they need to do within reason.

What would you add to this list?

I would love to hear some developer efficiency myths, truths, and partial truths from you. What do you think is making you less efficient? What do you think would make you more efficient? Share your thoughts in the discussion.

J.Ja

About

Justin James is the Lead Architect for Conigent.

77 comments
Edmund
Edmund

An obvious one is a clean comfortable work environment. Temperature variations, noise, chatter from other people; all can be serious distractions. OTOH, there's been enough times when I pull my head out of a problem to realize I got to go... NOW!

david.cuthill
david.cuthill

What about "The Man-Hour Myth". Does adding more programmers to a project get the project back on track? This was big topic 20 years ago. Required reading. Very few google-hits on the subject now. D.Cuthill

Paul W. Homer
Paul W. Homer

To me the greatest myth of them all is that "brute force" is faster than abstraction. So many programmers take KISS (keep it simple stupid) to the extreme and just power their way through the code, iterating out each and every step, over and over again. The opposite of tight, compact, abstract code is millions of lines of redundant, repetitive and inconsistent pain. If it was faster to input in the short-run, the inconsistencies, bugs and sheer size of that type of mess will easily wipe out any early efficiencies. Code always gets worse over time, and all code stays around for quite a while. If you start with less, you'll have to do less work to keep it going. Paul. http://theprogrammersparadox.blogspot.com/

mark.carolan
mark.carolan

All good points. And I second Edmund's about impossible deadlines. And may I add: Developers are interchangeable, much like factory process workers, so it's best to hire the cheapest ones. Amnazing how often I've seen that attitude in management.

salbert
salbert

Well, you have stated almost everything I could think of right now.But I believe there are some other things that could make a Developer to be less efficient.Things like Developers being restricted to a particular methodology in application development ...

rclark
rclark

Mostly because the commercial apps seem to think that more=better. M$ overuses XML and namespaces, and dreamweaver overuses stylesheets. Everything doesn't have to look like a foriegn language to work, be easy to understand and maintain. You don't need hooks into every possible comm object to get a web page on a screen. Notepad on the other hand is dumb. Just dumb enough to let me do my work. It is rudimentary, and could use a line counter and a better search and replace function. But I can slip into other IDE's if necessary. The other 90% of the time I just code directly in Notepad. Don't develop .Net in notepad though. I've trained dozens of high level developers over the years. Recently one of them sent me an email and thanked me for insisting that he always set up loops the same way, that every local variable is initialized prior to use. It saved his job for him and he was grateful. The point there is that on the job teaching is the most effective way to formalize your thinking. On the job learning is the most effective way to internalize concepts that are difficult to teach. So I agree that hobby programming keeps you fresh, but on the job training will advance your capabilities and make you more effective, much more efficiently. Use it or lose it. Hobby programming while it can broaden your horizons, unless used in the real world, will stale and fall away.

wcannon
wcannon

After 35+ years of professional software development, I will add the following -- enhancing the productivity of other developers has a greater multiplicative effect than most any individual tools or techniques. Some time planning for [inevitable] change will improve the productivity of many subsequent developers. Consider what types of change are likely, where they are likely to occur, how can the architecture support unexpected changes instead of being broken by them, build in support for change (e.g., factories, remote-able interfaces, and plug-in components, to name a few) etc. Write software from the beginning for others to support, either from a site different from yours, or at some future time (i.e., when you are not available). This means two things. (1) Write code that is easy to read. Forget trying to write "tight" code. Write easy-to-understand code. (2) Document the "high-level" aspects of your code. How do the modules interact? What is the high-level purpose and view of the algorithm/procedure (i.e., before ever dealing with special cases, etc.). Don't worry so much over the lower-level function- or block-level documentation. That part is pretty easy to decipher if you have the high-level view. Read "The Mythical Man-Month", by Brooks. Forget the "man-month" part, it is about writing software effectively. You will probably be surprised to learn that its wisdom is more applicable today than when it was written 40+ years ago about the IBM 360 OS project. The pictures and phrases introducing each chapter are priceless -- they make great slides for project status meetings! --Wayne

lalkishor
lalkishor

I do agree But having some comments Myths about what leads to developer efficiency This will make problems only if the programmer start learning programming though the DnD IDEs.. If he learn programming through console coding, he will able to do a self review before release in a better manner. Developer Efficiency. 1. More time, if the developer is idle 2. Lack of self motivation 3. As U said Environmental Factors 4. Family Issues 5. Distractions My Way... 1. Reduced distraction towards others thus now I am free from huge distractions by others. 2. Schedule time for distractions (Checking mails, making phone calls) 3. Schedule time for (1 Min each 1 hour) meditation 4. Always think you are happy, No problems at all.

edmicman1
edmicman1

Any links to task lamps and the like? We've got this horrible buzzing light above me (although, it's a big light and I'm not sure if they could turn it off...), but it'd be great to have some more "natural" light!

Saurondor
Saurondor

Test! Start testing as early as possible. Leaving it for last and believing you'll get back to it is a myth. "Exception handling done later" is also a myth. See above. Get an IDE with strong refactoring tools. The main draw back of working with Notepad is exactly this. It makes it hard to play with you're code as if it were a flexible element. Again see testing above.

stephen.scholtz
stephen.scholtz

Just a small comment, I find code hinting so useful to me as a developer, to save a few key strokes or let me know what methods/attributes are available to the object I'm working with. Any text editor or IDE worth it's salt has this. But why doesn't every other application on my computer do the same thing? I could write e-mails or specs or forum posts or notes so much faster if other apps would start making suggestions (non-invasively) based on common words I use.

jasocher
jasocher

One of the best things I've come across to help concentration is listening to music that has no lyrics. This usually means Classical (Mozart, Beethoven, Bach, etc) or some sort of club music (Trance, Progressive, Hard Dance, etc). Either of these types of music is just enough to keep all the background and distracting thoughts under wraps so I don't lose focus on what I'm working on. Since I've got noise-cancelling headphones as well, it also drowns out all the misc office white noise as well as conversations. I've got a whole bunch of Classical music saved in a playlist on seeqpod.com. If I'm in the mood for something to get my energy up, I'll queue up some of the channels at www.di.fm in WinAmp.

rick
rick

When I try to explain to people the frustrations of always being interrupted, I use the term "freight-train theory." Writing code is like a freight train - it takes a while to get things rolling from a dead stop. Just like a train, you don't set down a complex project for 5 minutes to reply to an email and just jump back to high speed. You have to "get rolling" again. As far as #2 (Practice Makes Perfect), I could not agree more. I think this how you separate the men from boys (in a nonsexist sense.) A true coder likes to write code. Period. That love of coding does not end at 5:00. One of my bosses used to refer to getting a problem solving idea late at night as "pulling a Rick." I could not tell you how many times I would be laying in bed or winding down for the evening and I would get an idea to solve a problem that was perplexing me from eariler in the day. Of course I had to know if it would work or not so I would have to go remote in and try it if possible. Real tech people in general think about tech quite often. If you are in tech and you have never done any playing, testing or tinkering outside of work, are you in the right field?

Mundo209
Mundo209

I agree with all of these. Can I come and work for you? I would add another myth that I encounter in my current job: - Providing an impossible deadline is motivational

Tony Hopkinson
Tony Hopkinson

I like a bit going on around me, makes me come up for air every now and then. It's been my experience that you are just as likely to concentrate on going seriously wrong as seriously right..... I particularly enjoy pair developing. It might not be the most efficient way of cranking out volumes of code, but just bouncing ideas off your colleague may cut down that volume... It is irritating when some twit says thay are too warm and your chair us directly under the air-con vent though. Shiver...

Tony Hopkinson
Tony Hopkinson

as simplyfying or re-use. Stream for instance is an excellent abstraction, chart as in VB chart, one of the most stupid I've ever seen. It's not really an OO specific thing just a new variant on a function call with many optional arguments. Code does indeed get worse over time, abstraction only helps if you get lucky or you keep that simple as well. One of the most horrible jobs in coding is to have to rejig a heavily used class hierarchy. In our world of deadlines, regression testing and risk assessment, you'll probably end up doing it all again, to avoid changing what you've got anyway. So now you have complex and replicated, this is not an improvement. If you have less functional descendants than you have 'levels' you've messed up.

wcannon
wcannon

Amen! There is what, a measured 20:1 ratio of productivity among software developers. Does anyone really think that the cheapest ones (by maybe a 2:1 salary ratio) are the most productive/$$? ... and how many ways can management mis-measure productivity -- individually productive folk who create interpersonal drama and drag down the team, folk who fix a dozen bugs a day yet created many themselves in the initial "productivity" rush, short-sighted productivity that creates long-term maintenance problems, etc., etc., etc.

Tony Hopkinson
Tony Hopkinson

for a lot of web stuff. My first web site I used Frontpage 98 for a about a two days. Hey I'd never done it before ! After realising how crap it was, got some books and did the job properly. If I've got hints and syntax highlighting that's fine. I don't want something writing the stuff for me though, not when I can do it a 100 times better and end up with a page that can be maintained and loads 400% faster. Habits developed on the job, the good ones are high value, I mean that's why you developed them. I pass mine on as well, little things like allocate something... Try {} Finally { deallocate it} Now fill in the logic... The payoff from something like this, is enormous, simply because 'some of us' aren't always clever enough to go put try finally in afterwards. For those of you who rely on the garbage collector, have you got a surpise coming or what. If you get half way down a pice of code and think to yourself I need to initialise this, do it now, always. It's easy to take code out you don't need, putting what you don't know you needed somewhere where it's needed is a smidgeon more difficult.

don.gulledge
don.gulledge

I prefer wordpad, than Notepad. But, I use it a lot. In the beginning, I could see that the table was the key to all web page formatting and spacing. Most the higher order products inject so many tables inside tables inside tables that you can never hand code any of it if you you had to. Figuring out the table, makes is fairly easy to do anything you want or need in Notepad or Wordpad. I like to code simple, clutterless web pages that leave out a lot of the extra stuff. I think everyone should learn to code a web page in a simple editor before using anything higher level.

Justin James
Justin James

Too true about the testing. Too true indeed! J.Ja

Tony Hopkinson
Tony Hopkinson

is to design it that way. Otherwise all the IDE does it let you know early this 'simple fix' is going to take a lot longer than you hoped.

Paul W. Homer
Paul W. Homer

It's probably an age thing, but I really don't like code hinting. When I'm typing I really hate things just spasmodically popping up on my screen. I find it disruptive. More importantly, if I am working with a language, library, interface, etc. I'd really rather prefer that it is simple and obvious. If I need the methods to pop up each time I try to write some code in order to remember how to use them, then the interface is too convoluted. I suspect that a lot of these modern IDEs, plus access to the Web, are really just propping up bad technology that should have gone away on its own because it is unusable. Which brings up another set of myths: #1: You spend most of your time when programming in typing in the code. #2: Faster typing means you are a faster programmer (and that you get more work done). Paul. http://theprogrammersparadox.blogspot.com/

Saurondor
Saurondor

Open Office does that. It will fill out with the word it predicts you're typing.

Tony Hopkinson
Tony Hopkinson

Common words could be built up and are in certain spellchecker interfaces. Next to no context though, which makes it almost useless except for spellchecking.

Justin James
Justin James

You have to be really careful with music, it really is not for everyone. I know some folks for whom it is really helpful; for me, I get distracted by it. I am someone who really prefers dead silence. Sadly, that is not possible in many (most) office environments. :( But, in terms of getting worrk done, lyric-less music is much easier for me to work in as well. J.Ja

rclark
rclark

"You know you are in a house full of geeks when your hubby and kids spend dinner discussing the nature of pi."

Justin James
Justin James

Glad you liked it. Yes, we are hiring, BTW... but I suspect it a bit long of a commute. :) J.Ja

Jaqui
Jaqui

different way of putting it, buddy developing. :D If you have a chance, try it with someone working on a completely different project. Though it seems counter productive, it actually helps. The different requirements and issues give a different look at your own project.

Paul W. Homer
Paul W. Homer

For me, an abstraction is a generalization of the underlying details. For instance, using a tree to represent a hierarchy. The data you want to collect for your users is some form of hierarchical structure (maybe reporting or management), but internally you structure this as a tree with n branches. The tree is a simplification, and it is reusable. It can hold a huge number of different hierarchies without having to be modified in any way. The brute force alternative is to code out the entire structure explicitly, essentially creating specific links for each job title and reporting structure. In the extreme, you could embed all of the data directly into code as 'functionality'. Nobody with experience or training would create a true brute force version of the code, but often they won't fully abstract the problem either; for fear of making it too complicated. A good abstraction isn't necessarily simpler than a small brute force implementation, but it is massively simpler than the combination of all of the similar brute force implementations in the same problem domain. In other words, you don't just solve the problem, you solve the 'class' of problems. If you write a 'tree processing engine', then you can reuse it over and over again while solving similar problems. The sign that you have headed in the right direction is that it keeps getting easier to get things done in the future, as opposed to harder. A good generalized abstract code base can be built upon quickly, creating a snowball like effect. I figure it is the architecture that keeps that engine separated from the others, making it easy to enhance it over time as the project expands. Drawing 'hard' lines and interfaces insures that the key pieces are always decoupled. If you've got the mix right, rejiging (refactoring) a heavily used set of classes shouldn't be a problem. The architectural lines define the boundaries of the work. You can change the internals, verify them and then enhance the interface to open up the new capabilities. It can be done in multiple smaller steps, over several iterations thus avoiding many deadline issues. In my experience rejiging has only been a major problem when the architecture is a 'big ball of mud' and the coding style has been brute force. But these are things that can be fixed and in doing so, I have found that it makes your life easier. Paul. http://theprogrammersparadox.blogspot.com/

rclark
rclark

In that story, they had to be drilled to always cut and pack the crystal because they would become inthralled with the music of the crystal. We get that way when we "Sing Silicon". We are so wrapped up in the design and coding, that we forget to initialize our data structures, and forget to do garbage collection, and close files, release threads, etc. The IDE may do some of that for us as a default. It is always subject to change, and when the paradigm changes, and we go to a paradigm that does not allow for auto(insert your failability here) then we have stable programs that have worked for years suddenly blowing up. Always, Always, Always code as if it all depended on you. Then if you forget something and the OS/IDE helps you out fine. If it doesn't, you'll have fewer Blue Moon Thursdays.

Bad Boys Drive Audi
Bad Boys Drive Audi

In the beginning, I used Frontpage for all of 4 hours and said "Screw This!", and went straight for Notepad. I didn't have to worry about it reformatting my code, adding in all sorts of crap, etc. I'm at a very different place though right now. I'd highly advise AGAINST using Notepad for .NET development. I'd advise using an IDE for most of your development in today's age. However, I'm still one to quickly throw a single file to Notepad just to check things out. I wish Notepad had line number support and better search/replace functionality. Still though, any entry level programmer I instruct always starts off in Notepad. Let's learn how to do it first -- then I'll give you the tools to do it faster. This is the EXACT same concept as using a calculator for math.

Saurondor
Saurondor

over time. No matter how bad it is written. Good design plus IDE means way less time than bad design plus IDE, but good design minus IDE means human doing repetitive tasks with a possibility of failure (leading to broken software). Bad design minus IDE means hell. Bad design plus IDE means learning possibility and room for improvement. Overall an IDE cuts down times required to change things which invites the developer to try new designs and thus learn. For example adding an interface declaration will be greatly assisted by an IDE. Detecting non compliant classes and requesting to add non implemented methods. Those methods can be added with a click and a TODO item inserted in the projects TODO list. The examples can be extended to getter-setter declarations, xml validation, checking code for best practices, etc etc.

don.gulledge
don.gulledge

Having begun some time back, a text editor is a luxury item. I used Volkwriter with the format set to a "*" at the 255 mark of the line, and it gave me a better editing environment than most anything since. I'd use it even today if it weren't DOS. You could copy columns, not just lines. Seems like every time we improve/advance, we still take a step backwards. The intelligent interface is for some like me more of a nuisance screen, than anything else. I used to love working after hours and sometimes still do. I'd do the core stuff during the day, but spend the evenings working on the UI/graphical areas where a relaxed creative spirit was better and easier to have. Except when the wife would bother you and ask when your going to have time for me. Regex sounds more like a gimmick than a real tool except for the simplist things which Find/replace can do some fairly good things. When they bring column coping/pasting back, then I'll praise the editor, no matter whose it is.

Justin James
Justin James

Code hinting helps me when working with an unfamiliar library, but I find in some ways it is counter productive. Instead of exploring a library's documentation to learn what its capabilities and limitations are, I take the first thing that looks like it does what I want. You are dead on regarding the amount of typing. If you are typing all day long, you aren't programming. Indeed, most programs really do not need that much typing, it's the debugging, testing, and design that takes time. J.Ja

Tony Hopkinson
Tony Hopkinson

Some pratt posting that being two fingered slowed a programmer down. When teh #08#08#08 he best way to speed is up is to make every other key backspace. :D

rick
rick

In college I managed a CD Store where the average customer was a 42 year-old female. Our overhead play consisted of mostly Jazz and Adult Contemporary (Neil Diamond, Tom Jones etc.) - stuff I didn't listen to. We also used to get a ton of free CD's from vendors (Sony, BMG etc.) of lesser known AC and Jazz bands. The whole experience gave me a much greater knowledge (and collection) of music, much of which dominates my playlist during development time today. I like rock music but I usually cannot develop to rock music. My fingers go from typing to drumming in no time. Jazz and Classical however are a different story. There a lot of studies out there that show that classical music helps you think better. Everyone in my area knows the problem is serious if I break out the classical music :) Because I don't speak a foreign language, world music works pretty good too (Buena Vista Social Club, Nachito Herrera etc.)

Tony Hopkinson
Tony Hopkinson

for us across the pond types. :D Unless you are straight coding, it nearly always works better, and you get two people familiar with the code... I didn't think I'd like it, but it's sort of like jammimg for developers. :p

Tony Hopkinson
Tony Hopkinson

Seen those and they make my point from another direction. I get a lot out of the concept, But tp paraphrase I want to apply it, not have it apply me. Those single track one shot designs were probably bashed together by someone who only read the first half of the sentence. You should use abstraction.....

rclark
rclark

Some von Neumann wannabe that generates abstraction for its own sake is just obfusion. I dearly love a good subroutine. One that you can either embed or copy. Also like classes that are true classes. One reason I dislike "C" is its insistance on untyped classes and overloading. It does give you power in construction and destruction, but you pay for that in cleanliness and clearness. Someday, somewhere, someone will come up with a language that harnesses the power of "C" and "PHP" and their types with the cleanliness of "COBOL" and we will have the ultimate language. IMHO.

wcannon
wcannon

It's true that there are as many models as designers. However, most of the modeling-related problems I've encountered are the result of one or both of the following two failures: (1) - Failure of the model to fit the real world: This is usually because the model (if there ever really was a model) was oriented to some implementation or algorithm the designer had in mind. Whatever the model, it needs to fit the real world. No matter what the change in requirements, it will still be a part of the real world. Therefore models that fit the real world are less likely to break and more likely to have a lower maintenance effort. (2) - Failure of the model to contribute any commonality: I can't tell you how many times I've seen designers gravitate to a one-off model that fits their immediate view of the world with no thought to providing leverage-able commonality (e.g., of base classes, algorithms, etc.). Forcing commonality is wrong, but the real world has lots of commonality among objects. Taking time to "discover" that commonality helps to avoid failure (1), above, in addition to the benefit of a more leverage-able design. Both of the above apply more strongly at higher levels in the software and have progressively less impact at low levels.

Tony Hopkinson
Tony Hopkinson

The 'best' model in theory is sometimes not the 'best' one in practice. As you gain experience, you pick up various mini patterns, that save resources, reduce rework are more amenable to future proofing... Tht's not even taking into account personal aestheic considerations, which have no noticeable impact at the compiled level, but make more 'sense' from a personal point of view. A model can be perfectly clear to 'you' and be complete gibberish to 'me', just as code can. We have to remember that code is a model and a model is an implementation. Simple can either be a metric, a value judgement or a common understanding. You should design ahead within a project, then within phases of a project, and then with an eye to future projects. At each level you should get more and nore sparing with how much that future proofing impacts what you are currently doing. That future may not happen and no matter how you look at it, you have increased the complexity of the design for potentially no reason whatsoever. OO if anything has made reuse abuse worse. So has patterns, in my opinion, many seem to equate common pattern with common code, a habit that in the old days left you with a function with twenty arguments.

wcannon
wcannon

Agreed, and what a mess it creates! It may be obvious, but I think too many people rush into coding too quickly. Most "designers" don't take time to "model" their application, including finding models that can be applied consistently and, hopefully, to more than just one object. The result is a mess. A well-modeled application yields classes and inheritance that cleanly fit the real world, and since changes will be of the real world, the model will support those new changes more cleanly, even though no one thought of them at the time of the initial design.

Tony Hopkinson
Tony Hopkinson

Unfortunately a lot of people out there are aware of OO concepts, but seem constitutionally incapable of applying them. In their haste to look damn clever, they start throwing classes and interfaces at everything. A couple of examples for you from this school of thought. How about a class dependant on 89 others ? Yes dead serious, I didn't believe my eyes either but one over educated moron did this. My most recent favorite was a small data transfer application that used 42 separate classes. Now it uses six. Guess whose is faster, smaller footprint, more maintainable, refactored and testable. OO provides very good tools, but you don't hammer screws in. The question is not how do I get abstraction in my design, but how can I make use of abstraction in my design. Obvious I know, so obvious a lot of people miss it.

rclark
rclark

Swap HOT and COLD.

Tony Hopkinson
Tony Hopkinson

(sci-fi books that should be a film) Who's going to play Killashandra Ree, and how can we work the nude scenes in? Pretty good analogy though, In the book successful singers learnt to do certain things without having to think about it before hand. Stuuf as basic as not holding something under the tap and waiting for the water to come out. I mean you don't think about turning it on do you? Course you get a problem if some one decides to do anti-clockwise = on. :D

Tony Hopkinson
Tony Hopkinson

If the design is right, the IDE makes it easier. All code does indeed changes, as does hardware, requirements.... Generally you find the people who have a problem with that do designs an AI couldn't help them with, never mind visual studio.

tuomo
tuomo

With all the "visual" editors we have gone a little backwards. Intelligent column handling is one, another are showing / hiding not just a function, procedure, between brackets, what ever but by a mask or search argument and just manipulating those lines. Not so much in writing new code but invaluable when trying to fix or even see what old code does or reformatting some spaghetti code readable. Of course it can be done running the code through filters, etc but that's too many steps and have to very careful not losing any information or breaking a comment. Which brings me to C compilers, one mistype and thousands of errors, warnings, etc. I'm still so used to for ex. PL/I compilers which are able to tell the error, isolate it and check the rest of the code without confusion. If you ever used (i)SPF with a good SC/CM engine you know what I'm talking. And don't get me started of thousands includes with name(space) problems, conflicting redefines, types, etc. In a large system - can be a nightmare after vendor/company "standard" library upgrade, change in objects, defaults, macros, etc. Slows you down and a lot sometimes.

tuomo
tuomo

I totally agree except maybe the debugging if you are not fixing some old code OR using debugging for testing / learning tool. Me too, lazy programmers, take first hint of possible hundreds, usually the wrong one(heh!). And I agree, nothing beats the real knowledge but sometimes it can be handy. If you have a SC/CM system that supports your development environment (not the other way around like what I see today, no names!) all your company code, objects, methods, procedures, structures, etc can be hinted WITH documentation - very valuable when fixing a large application system you see first time on Saturday night! Just haven't seen one since I left the mainframe development environment? Do they still exist?