I’ve gotten pretty worked up lately about comments from those developers who frequently hack stuff together and apply code & run atmospheres in their shops because they just don’t know any better and think this is the way to satisfy the business and their development team.
What am I talking about? Comments like this:
“Oh I’ve read articles before from people like that. A lot of that is just academic and theory, and not reality”
“You’re trying to make too perfect of code”
“The UI doesn’t need to be pretty”
“Just put it somewhere, it doesn’t really matter. I don’t care where it goes, just put it anywhere, whatever works”
If there are comments that really annoy me, those would be the top 4 and when you hear this consistently, it outright makes you want to just quit sometimes and give up because you’re working with people like this.
Comments like this are completely naive and are stated to dodge a discussion.
Let me break it down for you. “Academic” has nothing to do with:
- Properly scoping out a project based on some rough yet fairly detailed Functional & Technical specs
- Developing by small feature iterations that are actually achievable (part of Agile)
- Caring about a UI in that you do care about aesthetics. You do care about site flow. You do care about graphic designers because it all helps to translate to USABILITY
- Caring about design patterns in code and applying them (but not over architecting)
- Caring about clean code so that the next developer doesn’t get lost in a mess
- Caring about physically architecting files, projects, etc.
- using names that make sense for filenames, assembly/project names, folders to organize code files, etc.
- Think about MVC, you HAVE to!
- Actually prioritizing tasks based on “Business Needs”.
- Not bait and switching every other day based on no reason other than this or that person thinks we need this feature but nobody actually thought about priority and ROI
- Applying all 3 types of testing: Unit testing, Quality Assurance, and Usability
This is not Academic, it’s smart business. It’s not just related to IT. If you create anything, are you going to blame engineers who care about producing a product that is maintainable and extensible and then say this is just being “Academic” or this is “Only For Big Teams”?
It’s only those code & run developers that are the ones even using that kind of statement, and I resent the fact that these are the people running IT shops in a lot of cases.
Stop with the BS. Caring about producing quality extensible products has nothing to do with “Academic” vs. Real World. And give me a break, I know what over documentation is, what over planning is, and what scope creep is. It’s called Waterfall…been there. I’ve had people assume that’s what I’m talking about. Again, naive. And obviously you can tell when something is being over architected but in many cases the person saying it’s being over architected thinks so because they routinely settle for dirty code.
To say that because we want the team to continually focus (I’m not talking about “perfection” or “pretty”…please stop it with the BS) on clean code, manageable files with names that make sense, class names that make sense, method names that make sense, using Interfaces in design is no reason to come back with a statement that includes “Academic”.
In fact I came across an issue recently where I had an Ambiguous class name conflict because we did not think about naming some .aspx with names that make sense so consequently some DL classes had the same names and thus several Ambiguous references and name collisions that were totally avoidable. Most likely it was because of this mentality that “fast” is the only way to go that it we had that conflict in the first place because we were in a rush to get it to market.
If you’re one of these people who use excuses to dodge good process stated above, then I think you should rethink your profession and how you are abusing it.
Print | posted on Wednesday, October 07, 2009 10:10 PM
