But let’s be serious about this serious matter. Engineering software rarely is about developing it until it’s finished, delovering it and forgetting it with its user. We, or another engineer, will need to change and maintain it.

It’s ok to have something not following those best practices and standards and patterns. if that’s the best we can do NOW. But ASAP we MUST improve its quality, and by that I mean really DO it.

And there are some things we can do, even with not enough time or knowledge, to make it easier to enhance software quality after it’s already constructed, that doesn’t increase its developing time.

* Use Design Patterns, always! If you’re gonna access some data source, instead of messing SQL everywhere, at least create a DAO class and put all data access code in it as you gonna
* Use encapsulation! Really, keep responsibilities in their place and spend a minimum time thinking in operations interfaces. Internal code can be bad, but if interfaces are good, later you’ll be able to refactor as needed without messing anything else.
* Instead of building a “big” software, create a separated project and try small pieces of features. As you feel how it’s working, remake it into the main project. Or, create a Subversion branch, mess with the code then just see what has changed, create another branch and remake it. This way you won’t mix bad code into good and stable code, but will still use repository advantages.

If you really don’t know how to do it, develop a prototype instead of pretending to develop a production-quality software. Present it to user/customer as a demonstration, explain you didn’t have enough time and just made it to get something to show and it is NOT good.

Developing prototype takes less effort than developing quality software, and even less than TRYING and failing to do it. Prototyping really reduce a lot of resources consumed, and help us better understand how it should be!

In my last prototype I created a very big form with hundreds of fields. It didn’t have any DTO, whole HTML was static, it was really unusable. But it was enough to present to customer, to get them to see it working, feel how it could be. For me to test a form layout that would fit all those fields and feel a validation scheme.

And now I’m remaking it, adding PHP, thinking in fields names, getting them from POST and setting in a DTO and getting back into input values. And the cool thing is that most HTML markup and whole CSS styles are being used, they were good enough!

Yes, they [should] know better, but they also know reality. If a developer is expected to get something done by (or close to) a given deadline, then they have to do what is required, including less than ideal code, if keeping their job and/or not being looked over for promotion is a concern.

At around 7 years experience, I expect I was still under the misconception (or delusion) that ideal environments are realistic [to exist or be used]. But trying to do things the “right way” (i.e. avoid unverified assumptions, think ahead, have a clear plan/direction) and fighting to improve the system eventually wears one out. Sure you can continue to do your own best, despite everyone/everything else, but eventually have to accept you can’t [always] force the system to improve (unless you create your own startup company or something). The stress of “fighting [too many of] the good fights” is not worth it.

And even experienced developers must accept that they don’t know everything [in their field]. That when starting something radically different from all their past experiences that some [blind] experimentation, and trial and error, is required to develop a valid understanding. One can not create a proper design [up front] if they don’t understand the domain it is for. So the choice is either do a lot of reading (over a long period) and still only have “classroom experience” to show for it (all theory, little practically), or to dive in and experiment and learn much quicker (with a clearer understanding). In an ideal world developers would be given adequate time to experiment and learn independent of the “real work”, but the reality (employer’s goal, budget constraints, clueless management) often makes it “on the job” learning instead.

In all, what I took from the original article was “don’t write garbage code for real products if you can avoid it (prototypes not being a real product), but also know your limitations and practicality”.

And for the record.. as early as 2-3 years of [for salaried] experience, I was probably better than most of my co-workers with 5, 10, and 15 (or more) years of experience. I was terrible at a lot of things (so not too much ego there), but _very_ good at programming, as it is mostly intuition for me.

Oh, and the other reason I don’t blindly put value on someone “just because” they have some degree is while formalized education is a great way to obtain large amount of [good] information quickly.. it also means that knowledge was spoon-fed to the student and within the mindset (or “box”) of the teacher/school/whatever. Where in cases of pure unbiased/untainted experimentation, one may make many more mistakes (say that 5 times fast), but in the end [can] have a better appreciation for the subtleties of what was learned and think outside that “box”.

No egotism, just a jerk. The comment was that anyone with any experience knows better. The point of listing my credentials was to show that I do have experience. If you think 7 years in programming is not any real experience, then I feel sorry for how long it took for you to grow in skills. I’ve been in a variety of environments, including absolute crap where we were Defect Driven Design (only way we knew the requirements were that someone threw in a defect with missing functionality). The point is that bad code is bad code. If you cannot abstract what needs to happen, then you have to re-write the same code over and over and over and over…

@giantism_strikes:

Wow.. I detect a hint of egotism from your comments, including the one where you rattle off all those fancy (yet ultimately meaningless) degrees. I’ve seen plenty of programmers, fresh out of college, but weren’t of any significant programming value until they had some experience in the real world (and not that contrived classroom stuff). I don’t care if someone has three PhD’s.. all that truly proves is they are good at school, and whether they are any good beyond that depends on each individual.

I too have worked as a developer for the government.. and in that time I have seen the existence of monolithic “projects to replace them all” (too Lord of the Rings-ee?) in an attempt to get rid of all the [working] legacy systems. But all they really did was spend _years_ trying to “design the universal framework”, while taking money from the budgets of projects actually used, until eventually its budget was cut too, and nothing really came out of it (except maybe a few prototypes that only worked in a limited scope). And I heard they had some damn smart people working on that project.. if their whole project implementation hadn’t been doomed from the start. I’ve also seen the same unrealistic “one pass” coding expectations when dealing with contracting companies.. where the contractors are only allowed to work on things that have been approved by the contract managers (due to legal requirements) and were expected to get their tasks done by certain deadlines with no allocation for going back to fix/refactor all the “just make it work” code. Since the government was paying for work to be done, the company didn’t want to eat the costs of having to pay their employees to do code cleaned up, only that the next cycle of tasks were assigned for the next deadline (so the company could get their next batch of billable hours paid by the government). This basically continues until portions of the project become so unmaintainable, due to all the patchwork on patchwork, over the years that a major rewrite HAS to be done just to be able to [realistically] incorporate any new requirements. Luckily, I wasn’t one of the contractors and could my code without one hand [always] tied behind my back.

7 years of experience huh? Let me know when you’ve had 20+ years, and you’d have to deal with the futility of some of these work environments (and as Dilbert would put it, “the numbing effect”).

No offense intented, but with your comment you’re the one who wants to look smart… and isn’t doing very well.
TDD is well-defined methodology which is mostly but not only associated with agile methodologies. Though agile is a lot about management, TDD is all about writing software, in a very practical way. It’s been around in software engineering for years. If someone claims that he’s a software engineer (you didn’t, I know) without having at least heard about TDD and without having had the curiosity to check by himself, that’s very sad. It’s like pretenting to be a computer enthousiast and never have heard about Linux…
That has nothing to do with insecure programmers: like design patterns, it’s a tool which solves some kind of problems and has to be adapted to one’s situation. And nobody’s forced to use it.
Of course, it’s not a magical thing that will ensure that everything will be perfect the first time ! We all know there is no silver bullet.
The base concept is quite simple: write a unit test, make it pass, repeat.
That looks easy and unproductive at first glance, I know, but there is more. First benefit is that you need to think your tests, and be always aware of what you want to achieve, and what are the edge cases. When you code something, you start by stating what you want to do exactly, you constrain it, then you do it. It helps not getting lost, especially for beginners who tend to write code which almost make coffee, but it in the end fails to meet the initial requirements and business rules.
While doing so, you must stay aware of mostly three things: DRY (don’t reppeat yourself), SRP (single responsibility principle), and dependencies. TDD is all about constant refactoring and abstrating. If one of your method or objects grows to much, you stop, you break it, and then you make all your tests green again. If you’re repeating yourself (and you will spot that easily), do the same. And if you encounter a dependency, abstract away (e.g. thanks to an interface), mock it up, and ensure that you inject the dependency in a way that makes your test itself independant from the real implementation. That is one of the biggest benefit from TDD, it leads to a design with a minimal coupling as you code. Your almost coding and designing at the same time. ;)
To understand it better around practical exemples, I’d recommend some reading, e.g. Erik Dietrich’s blog (examples are C# but should be understandable for any decnt developer), especially the 3-posts mini series “TDD for breaking problems apart” (
http://www.daedtech.com/tdd-for-breaking-problems-apart
http://www.daedtech.com/tdd-for-breaking-problems-apart-2-magic-boxes
http://www.daedtech.com/tdd-for-breaking-problems-apart-3-finishing-up ), or Mark Seemann’s blog (yeah, still .Net, it’s currently my working environment. But with a bit of search you’ll find examples in your favorite language easily I think. TDD is well implanted in open source communities and amongst technical writers).
And for anybody who doesn’t think that would suit him or can’t find the benefits, I’m fine with that, I’m not an integrist, so no need troll me.

Ahhh. So my natural tendency to run like a pack of wild dogs are chasing me when I hear new fangled, ambiguous and non descript terms that didn’t exist 10 years ago and is put forth as the the greatest programming secret ever discovered is a good thing?

It seems to me that Test Driven Development, a term I just recently started reading about, like in the last couple months or so, should be a natural occurrence when one is debugging code and wondering why al gore won’t get his rhythm out of the way so the thing will work.

Sorry, that just popped into my head and shot out my fingers.
I couldn’t help it, the humor made me do it.

At any rate, several years of crewel hardship has taught me that those who speak of mysteries that they cannot explain plainly; are either lying through their teeth or, or… No no, that’s it; they’re lying through their teeth.

So, until I get a good break down of what Test Driven Development is all about, a term by the way that was not spoken in any of the programming classes I took over the past few years, I will dismiss it as egotistical stupidity put forth by insecure programmers who have an uncontrollable urge to be seen as far more intelligent than they actually are.

Note: I don’t mind new terms if they clarify a theory or come with clarifying explanations. But it seems like every time I turn around there is this new term or phrase that is describing something that is already defined, and put forth as being better than the predecessor when it almost invariably turns out to not be any better than the predecessor, and brings into the mix more complications that tend to break good clean working code.

It’s one of the reasons I stopped pursuing programming. After several years of health issues, and getting chest pains whenever I’m stressed out, I just don’t need that kind of frustration.

One almost always knows what the desired output is…

You nailed. The OP talked about starting without a plan and without tests.

But if you know the outputs and (ostensibly) the inputs. Then you do have a test. If you know how the inputs are coming and you know where the outputs are going, then that is a plan.

So clearly, the whole premise here is flawed. The OP knew what he wanted out of this system. Sure, the underlying structures may have been crummy, but this is almost universally true. This is why UML is often just “crap”. The most you get out of UML is a reasonable tracking of the data that needs to exist at some point in time.

The first run of code is always about making that code “work” and pass all of the basic tests. Future runs of the code center around handling exceptions, improving performance or cleaning up the basic API to access that component.

I think the OP has some warped image of “the right way”. The premise that there is some “right way” involving tremendous amounts of planning and no code has been disproven for years.

We are always going to build software in these little increments of inputs and outputs. And those inputs/outputs are tests and they are plans. The code you write is a design and it is an architecture.

>>>
If you had no tests, how did you know it worked?
>>>

That’s the difference between those who are book smart,
and those of us who can look at a problem, and think
our way through to a solution.

Not everything that is written on paper works. Not
everything that is written on paper is accurate.

You can start working on a procedure that in your mind
should work but it doesn’t. How do you know that, because
you do have an idea of what the output should be. One
almost always knows what the desired output is, one just
does not always know exactly how to get there. That is
what this article is about. A situation where a problem
that was not previously encountered and therefore none
of the previously written code applied.

That’s when you just start writing code. One function
at a time. It’s a step by step process to determine
the solution to the problem. Planning can’t help you
because you just don’t know where to start. And since
your the only one on the project, you have no one to
do a back and forth discussion to get the ideas out.

I find it more difficult to try and plan out every nuance
regarding a program. But, if I sit down and just start
coding, the process of doing it turns into a step by
step, inspiration after inspiration resolution to the
problem.

I had a class where I was supposed to do a UML and all that
nifty planning you talk about. After trying to figure it out
for way to long that way, I just sat down and did the work
and then fished out the UML from there.

The mindset that I hear from so called professional coders
is no different from the mindset of those who criticized
and mocked Henry Ford because of his ignorance of history.
The man thought the Revolution happened in 1812.

OK, so the guy only had an 8 grade education from the
establishment’s point of view. As if that is more important
than the progress he made with the Automobile, creating
the middle class by turning his employees into potential
customers and the many other things he accomplished.

Certainly the man had a lot of negatives like the
insistence on taking credit for other peoples work
and ideas and the unfair and cruel way he treated
his only son Edsel Ford. But the things the establishment
criticized him for were not; in the grand scheme of
things; all that important.

So the revolution happened in 1776. But seriously,
are you going to keep a man in the poor house because
he mistakenly thinks it occurred in 1812? Do you hire
a programmer for his knowledge of history or his ability
to code?

1st – make it work
2nd – make it right
3rd – make it fast

And then the following sentence you say that you “got it working”.

If you had no tests, how did you know it worked?

My background is this: BS in CS, MS in CS, and 7 years of programming being my only source of income. During this time I have written government tax software, written medical research software, worked with the FDA on creating digital models for medical research, and worked in the DoD. In a few weeks, I am switching to R&D of surgical equipment. The point is that I have had plenty of real world experience across a wide range of businesses.

A good programmer can look at a problem and see how design patterns can be used. “Just getting it done” leads to horrible code libraries, non-reusable code, and difficult maintenance.

IMO/IME it’s programmers for which writing good code doesn’t come natural who use various excuses to write bad code. Once you get used to writing your code properly from the first version, it’s faster and more reliable to just always write good code.

I never could understand the justification that under time/deadline pressure you have to write bad code, or give up unit testing. That’s precisely the right recipe for being late.