Discussion in 'OT Technology' started by Peyomp, Aug 30, 2007.
Sometimes its damned confusing switching.
do C++ and C count as different?
main source of income:
SQL (mysql flavor)
php every now and then
I can't tell you how many times I've been trying to use perl code in PHP files ... doesn't work FYI.
.net (c#, vb)
umm some custom language we have here using XML or as I like to to refer to is as - The "OH MY GOD THIS IS HORRIBLE WHO WOULD EVER FUCKING DO THIS THIS WAY" language
home / pleasure
HTML / CSS / JS
XML / XSL
For Work #2:
ASP .Net 2.0 w/ C#
lotta peeps still writing vb6
in school at any time i could be doing 4 or so. c, java, assembly, vhdl last semester.
I don't mean in a fucking semester. I mean files open at the same time, back and forth to accomplish one thing.
This isn't 'how many languages do you know?'
You switch between t-sql/sql, jscript and html simultaneously? Lay off the caffeine.
I finish one then move onto another.
Write perl/java/MySQL at one end of a trsancation, then HTML/JS/CSS at the other end. You do it all together.
Do you at least write one end of the transaction in its entirety before writing the other end, or do you actually invent the protocol and revise both ends as you go along?
The transaction usually changes as I go, so it gets mixed.
Maybe you should take an hour or so to plan out the transaction so you can write it all in one shot without having to revise it.
Requirements change, and evolve. I can have the thing written in an hour, changing twice as I go. If I take an hour up front, I'll have a swell design... that won't hold up to the rigors of implementation. You have to do, to design. It its iterative.
No. You have to know how to implement, in order to design properly. That's why I consult with our web developers before I design anything that will run on the intarwebz, because my own web programming experience is negligible.
However, if you don't design first, your implementation will suck. The kind of in-depth revision needed to make an implementation designed to meet Requirement X instead meet Requirement Y without turning into a plate of spaghetti is cost-prohibitive, which is why unplanned code almost always sucks, which in turn is why up-front design exists in the first place.
You may not like to take the time to plan your shit out first, but if you actually did it, you'd cut your implementation time in half. As for requirement creep, if your clients are actually calling you up every half-hour to change what your product is supposed to accomplish, then you need to sit them down in a conference room and get them figure out WTF they actually need before you start wasting your time writing code, half of which will be obsolete by the time you're done.
Actually, I KNOW how to implement it before I do it each time. I do stop and think about it. But the first iteration is inevitably wrong. There is always something I haven't thought of, even if I sit there and spend 3 days writing a spec for each part, that requries revision. If I have 3 days in that spec, I'm going to hack the code I already have, instead of rewriting the whole thing. Which is why BDUF fails. The code will reflect these hacks and my attachment to the time I put in the spec.
Thats great you consult with experts. In this case, I am the expert.
Your first iteration sucks no matter what, but since it conforms to your spec, you think its good enough. We on the other hand do not lie to ourselves that way.
It is only cost prohibitive if you do a costly formal design up front. If on the other hand you embrace iterative design, it is not as costly, and you end up finishing any component with dynamic requirements in much less time. Uncertainty and revisions are the enemy of BDUF, and they are a wrench in the works. Iterative design on the otherhand accepts revisions as givens, and embraces this. If I took the time to write a spec up front of everything I did, I would be fired because I would be too damned slow, and I wouldn't be delivering a mostly working system very quickly that improves all the time. Which is what this project requires.
I take the time before each iteration to make the best design possible. But as there is no formal client... I am the person who must be satisfied, the situation is different. Each time I build anything, there are several ways to accomplish the task in terms of implementation, UI, etc. and I won't be in any position to write a spec up front unless I play a bit. Otherwise my spec would be worthless because it would not stand up to contact with the code. If there was a client to approve a scope of work, blah blah then I would take the time to do a rigorous spec up front and stick to it. Then i'd charge them for changes. Since there isn't, and since I am the usability guy I must satisfy, and the key requirement is that the system be elegant, maintainable and user friendly, it evolves as I go. If you've ever done UI design, you understand intuitively that you never get it quite right the first time. It sounds very much like you haven't, and that your experience doesn't apply in this domain. For a military rich client app, none of this would work and you would spend 10 times as long coding as I do. This is why every web framework made in the last 5 years has a test server and you fiddle as you go.
I know you were taught in college that anything not Big Design Up Front is folly, but you really ought to look into some of the more dynamic methodologies if you plan to work in other sectors. I understand that you were taught that this is 'Cowboy Coding,' but it is not. I've worked in a cowboy environment before, and that is not what we do. They never think about design. They just code each chunk off the top of their head. We think about design issues all the time. Thats the only reason we build such great systems in so little time. Something on the order of 25% of the time it takes the competition to get to market. We just know better than to think that we can possibly make a GOOD design without frequent design iterations. It works extremely well for us, as we beat the pants off of every BDUF or Cowboy shop we compete with.
Using this method, our team was able to code much of the system before it was POSSIBLE for us to have formal requirements. We proceeded with a minimal set of use cases, a macro design which basically consisted of library selections and a framework. And you know what? That code was easily adapted when we finally got them nailed down, because as our knowledge of what the product would look like grew, our code changed to meet this vision. And we had a working product at the same time that a traditional BDUF team would have had a design, and no product. Because we'd already implemented most of the system, wheare as they couldn't even begin, because so much was uknown that no formal design was possible.
Main Source of Income:
JAVA (J2ME and some J2EE)
Others I "know":
I dont really consider HTML/CSS/etc as languages, but I know those as well.
Hell, make is a language. Just declarative instead of imperative. Just like SQL. I mention HTML because I find it a little challenging to go between XML and HTML.
Read that. Learn it. It will make you a much better programmer.