Coming from humble Visual Basic 3.0 beginnings, by way of AmigaBasic, AppleSoft Basic, and Coleco Adam SmartBasic, I didn't get a lot of exposure to formal programming practice.
Jeff,
Thanks for the link. I’m glad to see people are reading this article. This is one of my fundamental philosophies of software. While process may help software, process is not software. It is easy to forget this, while focusing solely on the process.
If you ever discover that your process is preventing you from shipping software, it is time to change your process.
“Learning consists in adding to one’s stock day by day. The practice of Tao consists in subtracting day by day: subtracting and yet again subtracting until one has reached inactivity.”
-Lao Tzu
God! I love this blog! LOL. You don’t know how many articles on here describe my workplace to a tee. I’m having Dilbert Principle epiphanies in Machiavellian office politics.
I’m glad to see others with this same philosophy. I was starting to feel like I was the only one left on the planet that thought that software development was starting to move into some type of etherial, intangible “lost art” type of status. This is one of the rare cases where the journey is LESS important than the destination.
I even proposed a new acronym on my web site that would attempt to exclude everything but the key object oriented concepts. I called it SOOP (or Simple Object Orented Programming). It was my last, futile attempt at holding on to an era when software was designed, developed, and shipped within months.
If you are wondering, I’ve just spent a whole month forced to work on a project that is rougly a year behind schedule, and has produced almost no usable code. And, it is our 3rd or 4th (can’t even remember) attempt at producing a new client application at my company.
Sigh… I feel like I’m in a support group for lost productivity developers. Hi, my name is Josh, and I’m a lost productivity developer.
Heh. That’s okay. The problem has pretty much taken care of itself. For 2005, the project has been budget-reduced and de-scoped nearly out of existance. But thanks anyway.
Wow, Josh. That’s a pathological case. I see tendencies towards this where I work, but nothing that severe!
In a case like that you might try referring to McConnell’s Rapid Development; he has some chapters on how to recover derailed projects.
Many years ago I worked for a company that basically died of this disease, so I know exactly how this works. J2EE encourages this type of programming. My advice would be:
If your company has less than 500 employees, do not use J2EE. J2EE is for writing huge enterprise apps for very large companies to be maintained by hordes of programmers over long periods of time. That’s what it’s for.
If you are a small company, use Ruby, Python, or something like that.
The Agile way is my new hope for the future…Crystal
It was this Podcast with Alistair Cockburn that really woke my hope again.
a href="http://agiletoolkit.libsyn.com/index.php?post_id=170374"http://agiletoolkit.libsyn.com/index.php?post_id=170374/a
Here is an earlier one…
a href="http://www.vicasting.com/cast.aspx/iid/143541/"http://www.vicasting.com/cast.aspx/iid/143541//a
Ok, I can see your point, but I used to maintain a retail accounting system that first was written by a DOER (or so he thought), with no rhyme or reason to how he did something, his code was DONE all over the place, it was a nightmare to code to. The only reason it sold, it was cheap, barely got the job done, and had source code with it so you could fix whatever was broke, this was circa 1985+.
Their next version was written also by a DOER but with a little more Astronaut in him, and his code has reason, patterns, similarities, etc that made it so much better to code to, sold more, had more extensions (cause you could count on a pattern being there).
As for your philosophy of ‘I code therefore I am’ is WAY OFF. If you’re any good at what you do, assuming you are, its because you’re smart, not cause you’ve spent tons of time typing in programs.
I’m one of those “Formally trained software architects” and can tell you that those who are formally trained typically turn out better code than those who aren’t. I think you would agree, just cause you can code, doesn’t mean you should.
I have great respect for the guys who can come up with the high flying patterns, but even more respect for those that can implement them using 1/2 the code others do. ORM’s come to mind here, how many VB programmers scoffed at ORM’s in JAVA and other languages, only now to embrace in .NET?
Good Blog!
J
Hi Josh.
My name is Brian, and I’m a lost productivity developer. I was hired because of my TDD background to help fix an already late project. I proceeded to test a system that was no where near fufilling it’s requirements. There was no issue tracking system, I was the issue tracking system. Two months into employment i noticed i spent more time creating spreadsheets and sitting in meetings describing our poor progress, then contributing to said progress. I also realized fairly quick that the developers at the company, many years my senior, new very little of the actual requirements and .net. After four months of grueling work and weekend appearences. I was told “Well thats the last time we get a developer to do a QA job” by my boss upon completion of the task.
We have some code here that has something called a GlobalThingServer. Templated of course, and when instantiated is often used with his own smart pointer class which derives from a ObjectReference class which derives from a ReferenceCountedObject class. Sometimes… I just feel like giving up… :’(
My favorite response to people like this is, show me. Most people (especially from a traditional education background) are capable of endlessly postulating about ideas but when it comes to creating anything concrete they waffle. All the postulating and wordiness is just a defense mechanism that prevents them from having to make any real decisions (that they’d have to be responsible for). The statement show me is like the polite version of prove it chump.
If they can articulate the example in pesudo-code or graphically they were just struggling to break the barrier from theory to reality. If they can’t, either they are afraid to take chances (very bad) or they haven’t spent any time working on the issue and choose to cover by bull****ing (still pretty bad).
This works on teams but the sad fact is, many decision makers and managers moved up the latter by spending the first decade or two of their career on their knees. Oh well.
who is top at the astrounout
Heh. That’s okay. The problem has pretty much taken care of itself. For 2005, the project has been budget-reduced and de-scoped nearly out of existance. But thanks anyway.
http://elitpr.ru
The Doers and Talkers article seems to have gone missing. The link is broken, and I can’t find it anywhere on the site.
So there IS a name for what’s wrong with me!