Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Standard Software Development Environments?

timothy posted more than 2 years ago | from the here's-your-hole-punch-and-branding-iron dept.

Programming 362

First time accepted submitter sftwrdev97 writes "I have only been doing software development for about 5 years, and worked most of it at one company. I recently switched to a new company and am amazed at the lack of technology used in their development process. In my previous position, we used continuous integration, unit testing, automated regression testing, an industry standard (not open source) in version control, and tried to keep up with the latest tools, Java releases, etc. In the new position, there is no unit or regression testing, no continuous integration, compiled files are moved to the production environment basically by hand and there is no version control on them. The tools we are using have been unsupported for 5-7 years and we are still using old Java. I am just wondering since this is only my second job in the industry, is this the norm for most development environments? Or do most development environments try to keep up on technology or just use what ever gets them by?" What's it like in your neck of the woods?

cancel ×

362 comments

Sorry! There are no comments related to the filter you selected.

Visual Studio (0, Troll)

North Korea (2457866) | more than 2 years ago | (#37681514)

Like with everything, how companies do things vary quite a lot. If talking about standard development environments, Visual Studio is likely the most used way to go, along with plugins for it and Microsoft Exchange infrastructure inside. It's the most professional way at least. But since you seem to be Java developer, it probably doesn't apply, but if you move to C# or C/C++ then yes.

Re:Visual Studio (2)

MemoryDragon (544441) | more than 2 years ago | (#37681654)

Actually VStudio is only the most professional way if you are in a windows only world. I do server programming in banks and there you dont even see Microsoft outside of the desktops by miles.
Eclipse btw. is pretty much standard there, although I dont like that IDE to much, I prefer Idea.

Re:Visual Studio (1)

abigor (540274) | more than 2 years ago | (#37681752)

Obvious MS troll is obvious.

Re:Visual Studio (-1)

Anonymous Coward | more than 2 years ago | (#37681932)

I've used eclipse and I've used VS. you can hate MS if you will, but VS is the single best IDE currently in production.

Re:Visual Studio (1)

TheRaven64 (641858) | more than 2 years ago | (#37682020)

How's its Java syntax highlighting? Objective-C autocompletion? Visual nib editor?

Visual Studio is a nice IDE (the debugger is still probably the best for any mainstream platform), but it is very much a Windows IDE. If you're targeting Windows, then it's probably the right tool for the job. If you aren't, then it almost certainly isn't.

Re:Visual Studio (1)

shutdown -p now (807394) | more than 2 years ago | (#37681988)

This has exactly zero to do with the question asked in TFS.

Offshore everything. (0)

Anonymous Coward | more than 2 years ago | (#37681552)

We usually just send the grunt work to India, and let them handle the details.

Re:Offshore everything. (1)

hazah (807503) | more than 2 years ago | (#37681846)

My god! You are so helpful! Whatever would we do without you!

Its a wide spectrum (2)

devilsandy (556014) | more than 2 years ago | (#37681576)

you were at one end in earlier job and moved to the other end in new job.

Re:Its a wide spectrum (0)

Anonymous Coward | more than 2 years ago | (#37682102)

It's a wide spectrum even within some companies. At one end, a vendor of ours is shipping Flex applications, full jquery/css interfaces, and the like. On the other end (same vendor), they provide a tool that requires VB6 to compile initially and again if you add additional database instances. It's officially only supported on Windows 98/2000 and Excel 97/2000 (it runs - but isn't supported - in XP and Excel 2003). They have stated they will not be converting it to VB.net, yet their training and planning guides assume you have it built for your site.

Our own site is a mixed bag. We have SVN (and most people use it, albeit some grudgingly). Most of our development is based on supporting this vendor's languages (Oracle PL/SQL primarily, but small bits of C, Perl, COBOL and Java). No regression testing, limited automation, but we're managing version tracking OK at least.

No CI? No version control? (5, Insightful)

barrywalker (1855110) | more than 2 years ago | (#37681578)

Run. Fast. This company is doomed without basic software engineering discipline.

Re:No CI? No version control? (2)

ByOhTek (1181381) | more than 2 years ago | (#37681662)

I'd have to agree.

Keeping things safe and secure where I work is a challenge, and we have mandates (that are followed) that ALL of our software be within the manufacturers 'actively supported' lifecycle, plus no more than 90 days out of date in patches. Working things as out of date as described in TFS seems like a nightmare in terms of reliability, security and lack of features,

Re:No CI? No version control? (5, Insightful)

rihjol (904281) | more than 2 years ago | (#37682166)

Alternatively, if he likes the place, it's an opportunity to step up and say "here's how we can do things better." If it's well-received, it's an opportunity to show both expertise and leadership.

Re:No CI? No version control? (5, Insightful)

ranton (36917) | more than 2 years ago | (#37681850)

Agreed. From my experience the lack of continuous integration, unit testing, and automated regression testing is the norm, but the lack of version control is simply inexcusable. It's not like it's a new startup or anything; if their tools are already unsupported for 5-7 years then they have been working this way for at least a decade.

Every job you take is an opportunity to build your skillsets and improve your career, and I find it unlikely that this job is the best place to do either. Unless you are able to quickly get management support in your efforts to improve development practices (which could significantly improve your abilities depending on how involved you were with those processes at your last job), I don't see why you would want to work there. I cannot imagine your coworkers are the best of the best, and your IT management probably has no idea how to run a software development group. (I have seen small companies in an uncompetitive niche do well despite such environments, but then again I also know someone who won the lottery)

Then again in this economy at least you are working, and who knows how good the IT industry is doing in your area.

Re:No CI? No version control? (0)

Anonymous Coward | more than 2 years ago | (#37681868)

I think that's a pretty common misconception among programmers. Yes, all those tools certainly make life a hell of a lot easier, and going without can be an epic nightmare, and it might not be a bad idea to run. However, all the toys in the world can't save a shitty program or shitty programmers, and very talented programmers with a great program can overcome quite a bit.

Re:No CI? No version control? (1)

s73v3r (963317) | more than 2 years ago | (#37682116)

It's not a common misconception. It's very accurate. If they aren't doing these basic things, then what else are they doing wrong? What else are they burdening their developers with unnecessarily?

While it might be very possible that great programmers could overcome that, why the fuck would you want to?

Re:No CI? No version control? (1)

aws910 (671068) | more than 2 years ago | (#37682122)

I'd say going without these tools and procedures *will* make for an epic nightmare. Since any self-respecting software engineer can work from anyplace, you'll basically always be "on call". Therefore, it's pretty likely that one day, another engineer will hack together something sloppy for a fix on one thing, and that will break another thing, and you will need to take a break from your vacation. Since you've already been in a good spot, you can see how bad it *can* be. At any interview I'm on, I make a point to ask about their version control systems, ticketing systems, deployment environments, testing methodologies, etc. A lot of startups don't place much emphasis on these. I usually pass on these jobs. I'd rather have my free-time than make a boatload of $$. Looking at the big picture, I don't blame the developers for these oversights. I believe it should be the job of management to set company-wide standards for these things, and enforce the use of them. Personally, management may be amicable/generous, but in the end it's not a nice thing to do to any developer, whether the oversight is intentional or not. My advice would be to educate yourself on the specific advantages of these tools/procedures, discuss them with your fellow developers to get buy-in, then assemble a small group and educate management on them. When speaking to developers, emphasize quality of life, and with management, emphasize quality and stability.

Re:No CI? No version control? (2)

Anrego (830717) | more than 2 years ago | (#37681960)

I'd say it depends on what they are actually doing.

Rigid process and a solid tool set is usually a good thing.. but "room full of coders with a goal" can work in some situations.

As for the norm.. I'd say most companies fall in the middle. You've seen the two extremes. Most places have a handful of critical tools that are very well maintained and kept up to date.. and a whole bunch that are "we should really upgrade that" or "yeah, that's a messy pile of scripts, but it still works" and will usually have something between "20 person process with 8 layers of review and testing to roll the dev version into production" and "I'll just copy the file over after lunch" for their production management.

Honestly the more important thing to be looking at is the people you work with, not the tools they use. The situation you describe would seem to speak poorly of them, but must not judge a book by its cover and all that. Well motivated, focused, and intelligent people can make masterpieces in the shittiest environment.. all the expensive tools in the world can't make a shitty coder produce gold.

Flee Now (1)

Anonymous Coward | more than 2 years ago | (#37681580)

Start looking for a new job -- unless you are in a position of authority and can fix that train wreck.

Seriously. No version control is a sign of EPIC failure in any software group.

Don't even mess with it. Find a job with some professionals.

Re:Flee Now (2)

Bobby Onions (735795) | more than 2 years ago | (#37681648)

Not only this, the first time there's a fuck-up, you'll get the blame as you're the newcomer.

Without version control and a rigid deployment process, the fingers will be pointing faster than you can blink.

(Don't blink)

Re:Flee Now (1)

hedwards (940851) | more than 2 years ago | (#37681966)

I'd go so far as to say that it's probably something that the OP should have inquired about when being interviewed. Whoever is conducting the interview ought to be able to answer a basic question like that without having to go to too much trouble.

Every job has tools of the trade that are essential and a larger number of ones that are optional but greatly improve the efficiency of the job. A well run company will have all the mandatory ones, and in up to date versions, and probably a few of the optional ones as well. One of my previous employers used a crappy web app for a mandatory job function that would be down regularly. Suffice it to say that the company wasn't very well run in other ways.

I would say, fight or flight (4, Insightful)

SirGarlon (845873) | more than 2 years ago | (#37681986)

If your heart acquires strength, you will be able to remove blemishes from others without thinking evil of them.

Mohandas Gandhi

It is unusual for a software shop to be as immature in its tools and processes as your new employer. Rather than join in the chorus of voices condemning your employer, let me suggest an alternative.

Understand the reasons for the current situation. Professionals, especially engineers, usually have a rational basis for their choices. Perhaps they are disillusioned from having wasted time and energy in the past (see Test Automation Snake Oil [satisfice.com] ). Perhaps they have a few heroic individuals who hold everything together and don't see the need for tools. I have no idea. I cannot wrap my brain around how someone would try to get by without revision control but that's immaterial. You have to understand that before you can either change it, or learn to live with it.

Read the IEEE paper, How to Be a Star Engineer [ieee.org] . Then, be a star. Help your team see the value in some basic tools like version control. Introduce them. Train your peers. Proceed slowly and patiently. Talk to your managers and senior staff about the risks you can mitigate and be realistic about the costs of doing so. In other words, help your company do better software engineering.

It is very possible they hired you because you come from a disciplined engineering shop and can help them improve their practices.

Or you can take the coward's way out and flee before you try to teach anything or learn anything.

Re:I would say, fight or flight (2)

vlm (69642) | more than 2 years ago | (#37682074)

It is unusual for a software shop

Assuming its a software shop... I've never worked in one, but I have some decades doing dev work as basically a tool maker at a couple places. The guy's description sounds like a lot of embedded places I've worked where "things just kinda got out of hand" after starting as such simple little projects.

One minute you're basically writing a one page web cgi front end for "grep" and it seems like next thing you know, you're creating a giant data warehouse and statistical analysis system, wtf?

Re:I would say, fight or flight (1)

Frenzied Apathy (2473340) | more than 2 years ago | (#37682132)

+1 for this. A mature, reasoned, helpful post.

Re:Flee Now (1)

Anrego (830717) | more than 2 years ago | (#37682004)

Start looking for a new job -- unless you are in a position of authority and can fix that train wreck.

Or fix from below. The key to that is not being cocky.. introduce stuff slowly, in a "this might be a good idea" vice "you are all idiots for not using this" kinda way.

If the people you work with really are idiots, then yeah.. run. Fancy process and powerful dev tools won't fix bad programmers, and in fact will just make your life more hell because in addition to messing up the code, they will now mess up the process (ever seen someone try to use VC who just doesn't get it.. "but it compiles on _my_ box" .. it's not pretty).

Re:Flee Now (1)

wmbetts (1306001) | more than 2 years ago | (#37682076)

I run a small software company with 3 programmers on staff (my self included) and I use version control. There's no excuse to not use and I'd be scared of any place that didn't. Hell, I used it when it was just me and I was hoping to be able to hire other people someday.

Hell No! (0)

Anonymous Coward | more than 2 years ago | (#37681592)

Hell no! This is not normal - run away quickly!

Run, don't walk. (5, Insightful)

badboy_tw2002 (524611) | more than 2 years ago | (#37681594)

#1. That sounds horrible. If you're looking to do good dev work, time to bail immediately, and next time be sure to ask about process in your interview.

#2. On the other hand, if you're a career climber at this company, you can make huge impacts by driving the adoption of these kinds of processes, and will quickly vault your way to the top of the engineering pile. That assumes that this way isn't the grand design of some really stupid people, or that you don't have managers that will support this. In that case, see #1.

Re:Run, don't walk. (2)

Smallpond (221300) | more than 2 years ago | (#37681712)

#1 can be bad if some manager is just pulling stuff out of a catalog and imposing it on the developers. It can be good if the developers are on board with the process and had a hand in tailoring it to the way their group works. Technology alone doesn't make a good process.

Re:Run, don't walk. (1)

Bobby Onions (735795) | more than 2 years ago | (#37681744)

I wholeheartedly agree with you, but at one engagement of mine any kind of process improvement was met with hostility as the in-breds were paid handsomely for the overtime to fix the same old problems that occurred night-in, night-out.

They deliberately never fixed the root cause of the overnight problems, they just fixed the wonky data, restarted the relevant services and waited until the next evening and more overtime.

I only got the green light to improve things when there was a change of management. Needless to say, I didn't get invited to any social events after that.

Re:Run, don't walk. (1)

hedwards (940851) | more than 2 years ago | (#37681978)

If the OP is looking to get a good job in the future, he'd do well to bail right now. What gets nasty sometimes is if you make the mistake of sticking around an obviously incompetent firm, you tend to get some of it to rub off. It won't necessarily hurt your abilities, but some firms do become a sort of pox on ones CV.

Option 2 probably isn't viable (1)

bigsexyjoe (581721) | more than 2 years ago | (#37682130)

Option 2 probably isn't viable (although we don't know enough to make the call for sure). The place he works at likes being backwards, and the workers probably lacks tech enthusiasm. Updating things is difficult and error prone and its importance is for the long term and the benefits are non-obvious. OP probably can't do anything and will probably end up on the losing end of office politics if he tries.

This is the norm. (0)

Anonymous Coward | more than 2 years ago | (#37681628)

Most places simply accept that not using those types of tools helps the bottom line, and that it is the job of managers and developers alike to keep the goals in mind and have the vision to see them through to completion, or that bug tracking is an aspect of Support.

When you only have a couple people, you can get by without continuous integration tools or automated testing. The problem is convincing the business that growth is more than just adding warm bodies.

Re:This is the norm. (2)

cornface (900179) | more than 2 years ago | (#37681666)

A lot of the times things like this don't help the bottom line.

I've worked with a lot of developers who get on a kick about this development methodology or this version control or this framework or this pattern and if given any sort of leeway will shoehorn it into every single thing they have even a small stake in.

Sometimes there is a good fit, but often it is just adding pointless overhead and complexity to something that doesn't need it.

Re:This is the norm. (1)

Smallpond (221300) | more than 2 years ago | (#37681742)

Most places simply accept that not using those types of tools helps the bottom line, and that it is the job of managers and developers alike to keep the goals in mind and have the vision to see them through to completion, or that bug tracking is an aspect of Support.

When you only have a couple people, you can get by without continuous integration tools or automated testing. The problem is convincing the business that growth is more than just adding warm bodies.

What's the deal with CI? What's wrong with merging at completion of work units -- like 2-3 weeks instead of daily?

Re:This is the norm. (0)

Anonymous Coward | more than 2 years ago | (#37681770)

Bullshit.

No automated testing and no source control never help the bottom line. They only shift the expense of software development from "development" time to every other stage of the software process.. and usually at a much greater cost overall.

Manual testing is a massive time sink and not particularly good at finding problems. It's a necessary component because not everything can be automated -- but if you want to protect your bottom line you make sure you minimize it.

Continuous integration is the only thing that makes marginal sense to leave out.. but only with a small group of developers working on a small application with clearly defined modules and rigorous testing.

Re:This is the norm. (1)

Smallpond (221300) | more than 2 years ago | (#37682080)

Anything that can't be automatically tested should probably be redesigned to have some test hooks added. I/O can have some kind of loopback or test fixture, GUI testing is easy to automate, it's generally rare error conditions that can be hard to simulate. Those are the cases where you might need to add a way to inject errors upstream to force the condition.

Re:This is the norm. (0)

Anonymous Coward | more than 2 years ago | (#37682110)

Bullshit, I have never been in a position where they did not at least use source control.

Too many tools are a waste of time. (-1)

Anonymous Coward | more than 2 years ago | (#37681630)

Any development tool beyond a print statement is over-engineering.

Re:Too many tools are a waste of time. (2)

bondsbw (888959) | more than 2 years ago | (#37681678)

Any development tool beyond a print statement is over-engineering.

I hope you didn't use a web browser to make this comment. You wouldn't want to over-engineer your web experience, after all.

Wow! (0)

Anonymous Coward | more than 2 years ago | (#37681634)

That must suck. I would try to talk to the people in charge to see if they could get you guys something better. If that don't work, try getting the software for free if you know what I mean. (as long as your not in Belgium)

keeping up with the world (2)

lynnae (2439544) | more than 2 years ago | (#37681636)

regarding this company's practice. Yes it's common, no it's not a place you should work.

It's common because companies can be very very afraid of change, see IE6.

You shouldn't work there for much longer because you really should be getting experience that will let you move your career forward. How would you show a prospective employer that you have Enterprise experience for example. Or experience working in with distributed version control.

IDE wise, Netbeans, Eclipse, Visual Studio are all the big boys. I've only ever used Netbeans and Eclipse for Java (I prefer Netbeans). I use Redcar at home for Ruby development. And VS at work for .net.

Yes, and yes. (2)

MrEricSir (398214) | more than 2 years ago | (#37681642)

Yes, that's normal.

And yes, you should find a new job. Do you want to become a lazy programmer, or an excellent one? If it's the latter, you're in the wrong job.

Re:Yes, and yes. (2)

dr_leviathan (653441) | more than 2 years ago | (#37681782)

Yes and not necessarily.

I don't think you need to flee your new job yet. If the work is interesting and the company culture is decent then maybe it is worth sticking around. You could help upgrade the company's software pipeline. I'd start by trying to get them to move to a good version control system, then add an automated build system, and then add some unit tests and an automated test framework.

On the other hand, if it the corporate culture is only OK or bad then yeah... flee early.

The real world, unfortunately (1)

treerex (743007) | more than 2 years ago | (#37681650)

This is unfortunately just the way it is: some places do the Right Thing (for various meanings of Right Thing) and others do not. Now you'll know to ask about this kind of thing when you interview. :-)

This is your oportunity to really excell... (0)

Anonymous Coward | more than 2 years ago | (#37681652)

:-)

No, this is not the norm.

This sounds like a disaster.

-paul

Do what is necessary and right (4, Insightful)

bondsbw (888959) | more than 2 years ago | (#37681656)

When I started, we had SourceSafe for version control, and Visual Studio 2002. That was pretty much it. Now, a few colleagues and I have made CI and unit testing a norm (at least for projects we are involved with). We now use CruiseControl.NET for CI, MbUnit for unit testing, SpecFlow for BDD, and Subversion (VisualSVN) for source control. We have also upgraded our toolkit significantly with open source and commercial tools (such as Resharper, various Red Gate tools, and various control libraries).

The point: be your own advocate. The boss isn't going to care or even know about most of these things. Either that, or find a job where these are already established.

Heh (3, Interesting)

hondo77 (324058) | more than 2 years ago | (#37681660)

Welcome to the real world, sonny. Now get offa my lawn 'cause it's never as green as my neighbor's. ;-)

Seriously, though, different companies are just different. That's just the way it works. Some are seriously great. Some seriously suck. The rest are in-between.

Re:Heh (0)

Anonymous Coward | more than 2 years ago | (#37681984)

Your millage may vary.

Obvious interview questions you forgot to ask: (4, Informative)

Anonymous Coward | more than 2 years ago | (#37681664)

* Is there unit or regression testing?
* Do you use continuous integration?
* What is the workflow for moving items to the production environment?
* What version control system do you use?
* What tools are you using?
* What version of Java are you using?

Cost and size of company (5, Insightful)

Synerg1y (2169962) | more than 2 years ago | (#37681680)

To answer your question better, I would have to know the # of employees at both companies aka size and the IT budget. The question to ask is are they giving you the tools to be successful. To directly answer your question though, yes for smaller IT shops it's the norm, for dedicated IT service companies and larger corporations it certainly is not. Enterprise environments with the project flows you speak of all cost money, a lot of, system debuggers, analysts, QC are all people the bosses need to hire, and they do not usually come cheap.

Also at smaller shops it is up to you to take the initiative to upgrade usually since there is nobody else to do it and the bosses are typically busy with other stuff. As long as you are comfortable in it though it doesn't matter. What you'll notice is the standard is also lower, most CEO / boss people aren't ignorant / stupid enough to think that a smaller IT crew can produce the same quality as a bigger one, so everybody just rolls with the bugs and punches until a working product is ready.

If this is an IT firm though, and they are running outdated software, then chances are your management team is NOT IT and that is usually a good sign to run. I've only truelly enjoyed working with IT people when I approach the coding realm, and everybody else is kinda meh, but you do what you to to put bread on the table :)

As you become more independent though and possibly as your skill range widens, you may find things work out for the best in your career as there are more job paths to take. A common one is sql developer to sql dba, they are so closely related, experience can jump you from one to the other.

I'm basing this all on your going from a larger well organized shop to a smaller to less organized one based on you naming the practices and lack of. I guess it's always possible to have a shitty large IT shop too, just talk to Sony :)

Re:Cost and size of company (3, Insightful)

shutdown -p now (807394) | more than 2 years ago | (#37682010)

Even for smaller shops, it's definitely not the norm to have no version control at all.

Well, at least not for shops that are worth working at.

Deliberately behind the times (5, Informative)

BabaChazz (917957) | more than 2 years ago | (#37681684)

We've found that going with the Latest and Greatest causes a lot of grief: M$ has elected to change a lot of the way version control works with their 2010 update to VSS, for instance, and as we still have clients who insist on the more compact executables produced by Visual Studio 6 (11 years old now), we cannot upgrade any further than VS2008. On my current build machine, for instance, I have every VS version between VS6 and VS2008, and I use every one of them for building some part of some product.

That said, some form of version control is critical. All it takes is one fumble-fingered tech erasing a project (which is what spurred our installation of a source control system) or one showstopper bug introduced into the shipping product with no record of how it got there, and you quickly learn the value of having backed-up old source versions.

Your shop shows all the hallmarks of the single-developer shop that grew without direction, as they all do initially. I'd strongly suggest that it would be in your interests to try and get at least minimal tools together... and to update to a recent Java before you start losing sales because of an outdated and now unsupported platform.

Re:Deliberately behind the times (0)

Anonymous Coward | more than 2 years ago | (#37682022)

We've found that going with the Latest and Greatest MS causes a lot of grief:

FTFY. Asking a crap-merchant to deliver anything but crap is just a silly idea.

Re:Deliberately behind the times (1)

shutdown -p now (807394) | more than 2 years ago | (#37682044)

If you're using Visual SourceSafe, it's probably worse than not having any VCS at all. Reason being that VSS is extremely flaky and plain unreliable, but lures people into thinking that their code is safe because it's in a VCS (which is true of pretty much anything else, just not this case).

Kill it with fire, and upgrade to something that works. If you insist on using ancient software, run CVS - it's still better by a long shot.

Re:Deliberately behind the times (1)

BabaChazz (917957) | more than 2 years ago | (#37682164)

I won't argue about VSS' flakiness, but I will say that so far it has not failed us when we needed to revert. The flakiness starts when you want to do something less than straight-arrow, like split a project, and there a lot of the flakiness actually comes from the integration with the other VS tools. In my experience. Your mileage may vary.

Depends... (1)

Oswald McWeany (2428506) | more than 2 years ago | (#37681690)

In some small manufacturing plants you may find that is the norm.

Where software IS the business that will never fly.

I worked one place where there wasn't even a seperate test database. Test tables had "_test" applied to them.

My last week there I accidentally deleted a whole bunch of production data that locked everyone in the office out of some important functionality- took hours to get things back running.

Biggest mistake I ever made... LOL... although it makes me chuckle thinking back.

YES- it was an accident.
YES- I felt like a total doofus (although I kept telling them whilst there test needs to be seperated).
YES- I'm sure some people probably thought I did it on purpose.

Depends on the Economy (1)

realsilly (186931) | more than 2 years ago | (#37681694)

During any economic downturn, one of the first things to go in a development environment is the technical writers or requirements analysts, then testing, then good processes. I write technical documentation and requirements. In every job (unfortunately I've had a few), I've seen this pattern for I'm the first one to be let go and then hear from co-workers how everything falls apart from there.

If you're now in a large company, I would be amazed that they are that far behind in good practices, but it does happen. I'm in a situation now where those good practices are only just being put back into place. It's very difficult to change the mind-set of a skunk-works environment. Managers have a hard time justifying strict processes and procedures.

Good luck in this job if you stick it out, and if you don't see change, consider a move to a more stable development team.

This is your opportunity (3, Insightful)

Faramir (61801) | more than 2 years ago | (#37681702)

Instead of running - change things. Take it one step at a time. All these tools are valuable, but you can get by without some. Personally, I would start with Version Control, follow up with system/regression testing, then unit testing, continuous integration, and finally deployment process. I've never been in an environment with continuous integration. It hurts, and I'm trying to change that, but I've been picking my battles carefully and not pushed very hard on that one yet (challenges with integration into our version control platform). Don't run from the company, unless they're unable or unwilling to accept concrete proposals for changes. But be very cautious as the new guy. You don't want to continually annoy folks with your shiny new way of doing things. Be patient, research the reasons for each proposals, and try to work each one in over time.

Re:This is your opportunity (1)

Mia'cova (691309) | more than 2 years ago | (#37681830)

I'd try to identify the most time consuming and error prone manual operations. I wouldn't kick things off by pushing unit testing. Some people look at testing, documentation, etc as more of a tax than a benefit. If you can come up with some tools and scripts to automate those slow error-prone processes first, you'll get the entire team listening really fast. Figure out what helps your workflow and push it out to the rest of the team.

Wisdom (5, Insightful)

BigBuckHunter (722855) | more than 2 years ago | (#37681714)

Congratulations. You are now wiser than you were prior to accepting the position which you now fill. The next time you interview for a company, which sounds like it may be soon given your current situation, you will now possess an assorted list of queries when the interviewer asks, "Do you have any questions regarding the position or the company?".

Re:Wisdom (4, Insightful)

Unequivocal (155957) | more than 2 years ago | (#37682062)

I'd suggest being thoughtful in terms of how you ask those questions. If I'm interviewing someone and they give me the third degree on process stuff, I start worrying that they are a "process fanatic." Now don't get me wrong - I'm all for good dev process but there are some people who are fanatical and irritating and not nice to work with, and getting a lot of questions about it would be a small red flag. Just making this point to add nuance to your point.

I absolutely think you should inquire into what the technical and process aspects of the job look like (among others). Just be thoughtful about how you ask..

RSA One version behind (0)

Anonymous Coward | more than 2 years ago | (#37681716)

I work on a large multiyear project with 300+ people. We used RSA from IBM for java development. The version control system has changed over time. Since it is a long project we don't use the latest. Instead we are one version behind. There have been upgrades during the project but there was alot of care that we used versions that worked. There is enough people on the project that we are not doing things by hand like at your new position. Things are also very organized because we have been working on this a long time.

The "norm" is . . . there is no norm" (3, Informative)

PolygamousRanchKid (1290638) | more than 2 years ago | (#37681718)

It depends on the product and project that you are developing.

Research Prototype? Two developers? Quality not an issue? Need to be done as soon as possible for a demo? Maybe vi and make are all you need. The error reporting system can be post-its on a wall.

Long Term Product? Supporting multiple customers on multiple platforms? Man-rated? Well, you had better have all the doo-hickeys then.

I've seen both these methods work, and all types of mixes in between. Like I said, it depends on your product and project, there is no norm.

Re:The "norm" is . . . there is no norm" (1)

ClayDowling (629804) | more than 2 years ago | (#37681926)

Don't underestimate the power of vi and a makefile. They're actually powerful tools. Although I strongly recommend coupling them with version control, bug tracking, unit testing, and in an ideal world continuous integration testing.

Lol (1)

AlphaBit (1244464) | more than 2 years ago | (#37681720)

Welcome to the schizophrenic world of technology.

Relevant South Park quote: (0)

Anonymous Coward | more than 2 years ago | (#37681732)

KYLE'S FATHER
Do you understand?

KYLE
Yes. Yes, I do, Dad. Now let me tell
you how it works in the real world.

At your company, you've got a serious problem with management. It might be your direct managers, or it might be unreasonable demands of the higher ups forcing your direct manager to not get what s/he wants

You may not be (and are probably not) the first to bring this up, you'll need to speak with your direct manager about this.

. Management needs to realize that they need to readjust their priorities on how fast they can respond to things, and allow time / hours to be budgeted towards improving the development environments / tools / practices (which I'm sure your co-workers also are aware of).

    If they won't / can't make this happen, then hey, it's a paycheck, and you've said your piece.

At least VCS and IDE must be there (1)

apetrelli (1308945) | more than 2 years ago | (#37681762)

In all my jobs (I started in 2004, notice that I work in Italy) at least we had a VCS (CVS, Subversion or some horrible things like StartTeam or PVCS) and an IDE (mostly Eclipse).
In one place we even had functional testing and CI with Hudson. But the two pieces above are the minimum requirements for a decent job, IMHO.

Quit when you still can (1)

140Mandak262Jamuna (970587) | more than 2 years ago | (#37681768)

Buddy, send your resumes out and hope you get hired before the company goes under. It is very difficult to get a job if you are unemployed, even if it was through no fault of your own. No. It is no the norm. I have been with my company from almost its start up days. We always had source control and regression testing. Unit testing was spotty in the early days. We were on the bleeding edge of adopting new tech (C++ from the days it was a downloaded preprocessor for a C compiler). So it is not the norm even for start ups.

In the same boat (1)

Pat Attack (1353585) | more than 2 years ago | (#37681776)

I am not a software developer, but I am in a similar environment. I went from a media company that had over 20,000 employees to an insurance company that has 1300. The programming groups are just like your situation. What's frustrating is that the developers will release a change and not even notify us on the application support side.I find out about new versions when my users call me to complain about a bug.

This is definitely not normal (2)

dkleinsc (563838) | more than 2 years ago | (#37681800)

The good news is you can probably start doing some of this stuff on your own. For instance, you can probably set up git on your dev box and just use it for your own change management. You can definitely write unit tests for your code, although you may have to keep that fact hidden from your boss. Just start doing it.

If someone is running around in a panic of "I lost the version of the file from 3 days ago and we need to get it live right now!", use your version control and pull up the version from 3 days ago. When asked "How did you do that?" tell them all you can about the repo, so now you have 2 devs sharing code using a DVCS, and then he tells his buddy and so on, so that by the time management has to make a decision about whether to officially use DVCS the devs can say "We've been doing this for months and it's helped us work faster and recover from screw-ups quickly."

This all assumes that the organization is this bad because it doesn't know any better, not because it's actually being impeded by a manager who would be featured over on Daily WTF [slashdot.org] .

Re:This is definitely not normal (2)

dkleinsc (563838) | more than 2 years ago | (#37681904)

Sorry, obviously the link is incorrect. The correct link: The Daily WTF [thedailywtf.com] .

How big of a development environment we talking? (1)

Derekloffin (741455) | more than 2 years ago | (#37681802)

If you only have a handful of people, it may simply be that they have been taking the 'quick and dirty' approach to development for a while and just haven't had the initiative to change it. In such an environment I suspect a few suggestions for improvements would be met with interest, especially if you're willing to put the time in to implement such. Now, on the other hand, if you're talking a mid to large development crew, then I'd be worried. That speaks to some serious weakness in management that they are willing to cut corners behind the scenes. Still, again, it could simply be lack of initiative. If you speak up with some suggestions you could find them receptive to some change, especially if you can sell them on the improvements in productivity and such.

Sheer madness... (1)

Neurotrace (2382180) | more than 2 years ago | (#37681806)

I genuinely cringed when you said no version control. My opinion? Run away or revamp the whole system. All kinds of shit happens without version control.

Two Choices (1)

s73v3r (963317) | more than 2 years ago | (#37681808)

You have two choices: You can either push them to start adopting some better tools, ESPECIALLY VERSION CONTROL, or you can leave. Pushing these things will take quite a bit of effort, and it's quite possible that you will not be successful in your efforts. However, if you are, and can demonstrate to everyone what tangible improvements they bring, you'll be a hero. But remember, I said tangible improvements. You need to be able to communicate actual improvements that will come, in terms of bugs fixed earlier, number of crises prevented, stuff like that. You can't just say, "We should be using this stuff because it's good!"

The other choice, is simply to leave. Sad as it may be, there are a lot of places out there that are not doing these necessary things. And most of them don't see any need for them, as they don't easily translate to benefits for the customer. Places like this don't care about the developers, and would have no problem sending you on a multiple month death march. If you are not able to convince them to adopt these tools, drop them like a bad habit. Make sure they know that you are leaving because of their refusal to adopt these practices.

Yes, it is normal. (3, Interesting)

MagikSlinger (259969) | more than 2 years ago | (#37681816)

I've been in corporate IT for over 10 years now.

The corporate standard version for Crystal Reports was so old, the version wasn't even listed on their website.

They were creating classic ASP (not .Net) applications as recently as 2005.

The most recently approved version of Visual Studio is... 2005.

There are still active VB6 programmers in the company.

Most of my department uses VSS 5 (yes 5, not 6).

The main corporate Java web app servers were Java 1.4 until last year.

On the other hand, if you come work for my sub-group, we've recently decided to screw corporate standards. We use mercurial, continuous integration with Hudson, Glassfish, latest version of Eclipse IDE, Java 6 and jQuery. None of this is corporate "approved", but we get high marks from our users! ;-)

change takes time but the free tools are out there (1)

ncohafmuta (577957) | more than 2 years ago | (#37681828)

I don't agree that it's the norm, even for a small company. You don't need big money, esp. for java development.
We're small and we get by well. cvs, eclipse, junit, cruisecontrol, ant, rpm. Throw a little money for Jira and you're doing pretty well.
But you're there, so either run or try and change things. But believe me, it's not easy. Developers get engrained in ways of doing things. And even if it's for the better, changing that takes time. Convincing your boss and a senior dev guy to start is your best bet.

make the difference (0)

Anonymous Coward | more than 2 years ago | (#37681840)

Well, since you have experience with unit testing, version control, regression testing and the like, how about you make your case with your manager. Treat this as an opportunity, not a challenge. Your situation is typical for a company (or a department) that just existed out of 2-3 developers and had to expand.

depends (1)

rish87 (2460742) | more than 2 years ago | (#37681858)

If this new job is on either the gov or contractor side of the DoD, this is more than normal (did my time in that setting, never want to go back). This sort of development setting is also commonly found in larger companies outside of DoD. I've only been out of school a few years, but I've already learned a valuable lesson: bad development environments are caused by lack of caring from the dev team which leads to a horrible working environment if you actually care about programming. Unfortunately these bad settings tend to pay the most, but I assure you that working in a company surrounded by people who know and stay current in their field who are also passionate about the work being done (professionally and personally) is worth more than any amount of hard currency.

Very lucky in your first job (1)

plerner (2459036) | more than 2 years ago | (#37681862)

I think you where very lucky in your first job. I have had several jobs and only in one of them the manager considered that kind of tools. In the rest they always told me "Great idea, do it!"; "Thanks, then other people can now start using these tools, too. I may need a server to set it up"; "What? No, do it in you own time at home, I don't care about that stupid stuff, other people don't need that shit. Shut up and work!". That's the main reason why I keep changing jobs....

Start looking elsewhere if they don't step it up (1)

Sean (422) | more than 2 years ago | (#37681872)

Luckily for them you know what a proper development environment looks like. If they want to make it a top priority to improve in that area than great. If they don't see it that way find another job immediately. Life is too short to be stuck in a place like that.

Is all this ... thingies ... really necessary? (0)

Anonymous Coward | more than 2 years ago | (#37681876)

You assume that all the layers you described are necessary for software development, aren't you? The point is: All this infrastructure needs to be maintained. Have you ever checked how much time you spend with the real product? Or checked the overall cost?
Sometimes there are very good reasons for such a low-level approach.
I give you an example: I work in a private health insureance company that is more than 100 years old an has 5 million customers with about 20 million contracts and more than 50 millions of different tariffs and policies. Every day about 20 000 bills need to be processed. The base system is a zOs based mainframe. It has an uninterupted uptime of 11 years now!
Developing software for this environment is at the same time extremely challenging and extremely easy. It is challenging because one has to take care that the tools used must be available in 20 + years from now on. So the math is done with Fortran and SAS, database stuff is done with cobol etc.
The easy part is, that one needs not to learn the newes style or program, one can become a real master of the particular infrastructure and of the issues.
There is no need to run. There is a serious need to evaluate your situation: Do you understand why the development style is as it is? Do you understand the business idea that is behind this development style, if any? Maybe you find out that there are very good reason fot his. Or maybe you where hire because you have knowledge in the newest technology and it is hoped you can improve the situation.

Re:Is all this ... thingies ... really necessary? (1)

shutdown -p now (807394) | more than 2 years ago | (#37682104)

Version control is a must for any development more complicated than "hello, world", even when it's a one-man project. There are no ifs or buts about it. There's a reason why VCS date back 40 years.

Not in the industry (1)

Murdoch5 (1563847) | more than 2 years ago | (#37681910)

I want to stress that I'm not in the industry as a developer but I do work on coop doing some code development. Where I work on coop we use Perforce as the SCM tool of choice and it is horrible.

Outlining some of the problems I've had with Perforce:
1) All the tools to work with Perforce are sloppy and bulky, The GUI is horrible and does not have a usable work flow
2) Perforce is known to crash, I've personally seen the Depo get so messed up that the company I do coop for had to call Perforce and ask what to do
3) Perforce makes it hard to get the files uploaded and then has in the past completely prevented me from checking them out
4) Perforce doesn't allow you to change a files name when it's checked out, It should keep track of Inodes not file names
5) Perforce has horrible cross platform support, unlike GIT
6) Perforce has poor workspace support, If you mess around at all it will get more lost then a baby in a room of topless women
7) Perforce loves to make more then 1 workspace per user and not tell you
8) Perforce loves to lock up preventing you from getting access to your files
9) Perforce is extremely slow, it crawl in comparison to GIT
10) Perforce doesn't provide any actual customer help

I've had these same problems at school, where we also run Perforce in our program. When it comes to SCM there is one product that I promise is more trouble then it's worth and that is Perforce. I haven't made up a single point above, I have had every problem I mentioned and coming from a closed source software I should of had been nothing but a stellar experience.

If perforce wants to create a usable product they need to get rid of the GUI entirely, They do have a CLI but it's not the greatest. They need to create power shell tools to work it. They need to allow you to actually use the workspace and not manage it for you exclusively and they need to stop the freezing and crashing that plagues the software. .

Luckily there is a GIT which does fix all the problems i've had with Perforce and has left me with a wonderful solution to SCM. I even use GIT at school now above Perforce because it leaves me with a usable product that can hold up.

Who's in charge? (1)

ElmoGonzo (627753) | more than 2 years ago | (#37681914)

Sounds like a place I worked where the owner fancied himself a developer because he wrote the initial program in GWBasic. His fair-haired right-hand man wrote (probably still writes) some of the sloppiest code I have ever seen and when the boss man wants a change made he goes to "Karl" who "tweaks" the code solving the immediate problem and all too often creating a morass of workarounds and kludges which end up stifling attempts to extend the code. Rumor has it that they are still using a 12 year old IDE that was new when Win 98 was the latest, greatest thing on the block.

you just learned a valuable interviewing lesson (2)

Surt (22457) | more than 2 years ago | (#37681920)

And the lesson is, you need to ask more questions about the place you are interviewing. You wound up in an egregiously bad one because you didn't ask those questions. Remember in the future that at least one quarter of the interview should be devoted to you asking them questions, and if their interview practice doesn't allow for that, run away.

Yup, this is normal (1)

John Bresnahan (638668) | more than 2 years ago | (#37681928)

Unfortunately, this sounds like almost every company for which I've worked.

At one job, we were using the same hardware and software that had been used about eight years earlier to originally develop the software. Nobody, including the other developers, saw any reason to change a thing. At one point, the secretaries were getting new machines, so we grabbed their old machines which were still much newer than any of our development boxes.

The only company I ever worked for that provided up-to-date hardware and software went out of business after six months, in part because they were spending so much money on "cool stuff" whether they needed it or not. (Lesson learned from the dot-com craze: Don't get expensive office space, fancy and expensive working "environments" and other perks until you actually have a revenue stream!)

Version control first (1)

Animats (122034) | more than 2 years ago | (#37681930)

Top priority is version control. Without that, you don't know where you are. Which version control system doesn't matter that much. They all work well for small projects.

At least put YOUR changes on a VCS! (2)

GPLHost-Thomas (1330431) | more than 2 years ago | (#37681942)

If there's no VCS in the company, I'd use one at least for myself and my own code. Then if you use a distributed system like Git or Mercurial, you don't even have to ask anyone, it can become viral, and you don't need any piece of infrastructure that doesn't exist already (there's always a way to send patches, using a USB key, a mail attachment, etc.).

Nothing worse than a bloated dev environment (2)

elloGov (1217998) | more than 2 years ago | (#37681944)

Here are my two cents: In any team environment, a good version/source management is a must. Build and deployment processes should also be examined. Shell scripting will go a long way to automate and alleviate many of your recurring headaches. With that said, there is nothing that annoys me more than employing industry standard buzz words for any and every solution, thus bloating the development process. As a developer, I always appreciate a thin development environment that allows me to do more development and less infrastructure, third-party software debugging.

Make the software open source! (3, Funny)

Lieutenant_Dan (583843) | more than 2 years ago | (#37681964)

It is obvious to everyone that you could harness the synergies that the OSS movement provides by convincing senior management at your new company to make the software open source. I would encourage you to take the initial step and putting the source code on torrents right now, which would show effective leadership and a long-term vision that your new company greatly requires.

By making it open source you will find that there are very mature methodologies for version control and the likelihood that your code will be forked is almost zero (76% to be exact, or in decimal terms 0.76 which is pretty close to zero, more so than 12). Regression testing will be addressed by the multitude of your clients who will willingly give up their slack time to test the product and provide valuable Q&A. You will then need to merely glance at the feedback forum that you will set-up at your $4.99 LAMP web host to get a high-level view of the pertinent concerns.

And use Ruby on Rails; it's the future.

Only when we free ourselves from the dichotomy of corporate greed and lack of client-facing event management, can we attain new heights that will make your company stand out from the rest of software makers out there.

Which is nice.

56 posts and no one asked why? (5, Insightful)

vlm (69642) | more than 2 years ago | (#37681972)

56 posts so far and no one asked why? This is the crucial question.

1) They hired you specifically because YOU know good dev practices and management wants to model everything after you, or at least after your former employer. Well, golden boy, stay put and rake in the cash. Should be easy to angle into a management job assuming you want that. Maybe the boss thinks he's getting a promotion and is trying to put you as his protege.

2) They started so small they didn't need those things. Now they're big, so they hired a guy from a big time operator. Sounds like it won't be too tough to convince them the new big guy comes with a new big VCS or a new big testing system.

3) They're planning on selling / getting out of the field and just need to keep you around until the sale or bankruptcy is final, or they're completely bonkers insane. Run like hell

Also you have to factor in the change difficulty level. Is your team... just you? Then what the heck does the boss care what your VCS is, just roll one out. Is your team also fed up old timers who know better? or is your team all clueless noobs? Will IT slap you on the back and buy you a beer if you install a GIT repo "hub" like gitolite, or take you out back and shoot you? How bout management?

Version Control a must. IDE useful too. (2)

aristotle-dude (626586) | more than 2 years ago | (#37682034)

A lot of people who talk about the Visual Studio are probably not using a stock install but most likely using addons like Resharper to give them the functionality they enjoy.

If you are focused on Java but like the ease of use of Visual Studio + Resharper then take a look at Intelli-J. It is a Java IDE written by the same guys that produced Resharper for VS.NET so you are going to see a lot of similarities between the two products.

I would stay away from GIT and other system popular in the blogosphere and go with SVN as it is tried and true or evaluate Perforce to see if it fits within your budget.

As for continuous integration, look into CruiseControl or something similar.

Leave the company (1)

prefec2 (875483) | more than 2 years ago | (#37682054)

Using version control is an standard thing to do in software development. This even applies to the embedded system. Unit-tests are not widely used. However, not using them is stupid. The same applies to other more elaborate test mechanisms. Continuous integration is not used in all companies, but the use is becoming more common lately.

If you are able to establish a tool landscape in your company then that would be a move in the right direction. What you also need is an agile development approach instead of the fumbling around approach. Agile is required, as requirements are never totally known at project start. They normally form in a longer process. Therefore you need also to support aspect oriented methods and feature driven development. And you should design for change and include monitoring in your enterprise application.

If all these things are possible you actually can stay with the company.

Where I am... (1)

CompMD (522020) | more than 2 years ago | (#37682060)

My employer makes spiffy gadgets for the automotive market, and you may own one of our products. Commonly, developers have VS for building code in a simulator and CodeWright for developing code to run on an embedded device. Version control is done with Git, CI with Jenkins, code review with Gerrit, issue tracking with Jira.

sadly (2)

Charliemopps (1157495) | more than 2 years ago | (#37682066)

Sadly it IS normal. But there's a paycheck right? Stay there until there's something that pays more... then leave.

Make it better (0)

Anonymous Coward | more than 2 years ago | (#37682106)

I was the driving force behind one employers adoption of version control, and of migrating off a vendor-specific language. If they are willing to change, you can make a big difference, and version control is an easy sell - everyone has a horror story about deleting something important.

Dev environments and testing are much more variable - some places do not support SOTA testing, and you may have to get used to it. Some places don't have any way to emulate the deployment environment.

Most Companies (1)

Greyfox (87712) | more than 2 years ago | (#37682108)

Most companies don't know how to do software development, especially if they're not software development shops. If the project is a small one-or-two person project they might even be able to get away without version control for a while. It's pretty much impossible to scale up past that point though. Even fewer companies than have version control have good change management. So you'll never be absolutely sure what's deployed on production or whether you can rebuild the production servers from scratch if you need to.

Sometimes they'll listen to reason, though. It's usually pretty easy to get a version control system set up. Might be a bit harder to get them to agree to a legitimate test environment if they don't already have one. They might at least allow you to build one with vmware. Drop in a build and deploy process and the development environment would be almost civilized.

If they're not keen on any of that you'd be better off finding a real software shop to work in.

You have your work cut out for you (1)

Dan Morenus (179942) | more than 2 years ago | (#37682114)

If the company is a start-up, then they need to get some process fast or they are one disk crash away from oblivion. If they've been around long enough to know better then you might want to move on now. Either way you can try to encourage them to adopt some process first, then if it just isn't going to happen look for a new job. They absolutely must have a source control system and offsite backups. It doesn't matter what's normal, not having source control is like not having toilet paper in the bathroom. Even a one-person development team should use it. Offsite backups are literally your fire insurance. The other things you mentioned are all good to have, and their presence or absence may give you some idea of the relative maturity of the business, but version control and backups are absolutely non-negotiable. Java versions are a little different. There, you may be forced to develop in an older version to support a customer that's slow to change their client configurations. This can be true especially when your clients are businesses rather than individuals. At one job I was developing in Java 1.1 for a long time because our biggest customer was running Netscape 4 on OS/2 at 6000 locations and that was the latest version they could handle. The software still worked fine for folks with newer browsers and JREs, I just didn't get to use Swing and a host of other niceties.

I"m surprised... (1)

Anonymous Coward | more than 2 years ago | (#37682124)

... at how many of the comments say to run from the company because they don't have good software practices and look for a job where that stuff is already in place. It makes me wonder how many people think that a company should just hand everything to you.

If you see a problem in the company, where you know you can add the value of good software engineering practices, fix it. You looking for career advancement? What looks better on a resume? A person who switches jobs because they don't have what he wants implemented? Or a person who sees a problem, presents a solution, implements it and learns how to deal with it? Which choice screams of career advancement?

Yes, it will be a risk and maybe it will get turned down, but at least make an effort. In software development, people tend to get caught up in their own little "programming" worlds and fail to see the big picture. Really, if you like the people you are working with, then just try to show them why they should be developing it the way you think it should be. If they argue that they don't want to change because of money, show them how much they can save by doing it your way. If they still don't agree and can't give valid reasons why they don't want to change, then it may be time to consider looking, because they aren't really looking for your input at that point and aren't really amenable to change.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>