Jump to content

  • Log In with Google      Sign In   
  • Create Account


I've been "cowboy coding" on the job most of the time. How do I get away from it?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
30 replies to this topic

#21 tstrimple   Prime Members   -  Reputation: 1718

Posted 12 October 2011 - 12:24 PM

Maybe software engineering Isn't so overrun by sheep as I originally thought.


Just depends on where you spend your time. It's one of the many reasons I love stackoverflow these days.

Sponsor:

#22 phantom   Moderators   -  Reputation: 6805

Posted 12 October 2011 - 02:26 PM

But there was a problem - I had decided that the user should be able to add any kind of data in the description of each to-do item. On my pages this was fine, but on the pages of the other two programmers, who were putting data right out of the DB and onto the page without htmlspecialchars() escaping, there were several script injection faults. The reason for this was the combination of two oversights; I had not considered the implications of allowing users to enter any data, because *my* pages were OK with this data; I had gone off and asked somebody more experienced how to support this safely. The other two guys had not considered the implications of dumping data right out of the database, because their input data did not allow html special chars.

The solution, which I have now learned to provide in future, is to provide a data access method along the lines of getPageSafeData() which performs all the page safe escaping for you. This way, next time I work with noobs, I can be sure my data isnt going to inject nasty things into their pages.


Honestly, reading this, you are all "noobs".
"I decided"... "they decided"... congrats you all failed Communication Skills 101.

There should have been no 'I' or 'they' in that, there should have been 'we' and you all should have decided on the right way to do things.

But don't worry, I've worked with people like you, deciding the 'right' way to do things without letting others who might need to know know... in fact I ran into that problem last week where, having communicated quite clearly with group leads over a couple of weeks that I was working on and changing file formats I came in one morning to discover one group had decided to change a file format without bothing to inform me.

So, complain about 'noobs' all you like but if you had all been following 'best practise' your problem might not have happened... and if you had talked and not just decided things on your own, well, same deal... but by all means, carry on in your little bubble where you are right :)

#23 JustChris   Members   -  Reputation: 149

Posted 12 October 2011 - 03:02 PM


But there was a problem - I had decided that the user should be able to add any kind of data in the description of each to-do item. On my pages this was fine, but on the pages of the other two programmers, who were putting data right out of the DB and onto the page without htmlspecialchars() escaping, there were several script injection faults. The reason for this was the combination of two oversights; I had not considered the implications of allowing users to enter any data, because *my* pages were OK with this data; I had gone off and asked somebody more experienced how to support this safely. The other two guys had not considered the implications of dumping data right out of the database, because their input data did not allow html special chars.

The solution, which I have now learned to provide in future, is to provide a data access method along the lines of getPageSafeData() which performs all the page safe escaping for you. This way, next time I work with noobs, I can be sure my data isnt going to inject nasty things into their pages.


Honestly, reading this, you are all "noobs".
"I decided"... "they decided"... congrats you all failed Communication Skills 101.

There should have been no 'I' or 'they' in that, there should have been 'we' and you all should have decided on the right way to do things.

But don't worry, I've worked with people like you, deciding the 'right' way to do things without letting others who might need to know...
....

So, complain about 'noobs' all you like but if you had all been following 'best practise' your problem might not have happened... and if you had talked and not just decided things on your own, well, same deal... but by all means, carry on in your little bubble where you are right :)


I guess there is a little bit of a cowboy coder in all of us Posted Image
Electronic Meteor - My experiences with XNA and game development

#24 Antheus   Members   -  Reputation: 2393

Posted 12 October 2011 - 03:37 PM

Needs must when the devil drives. Having had this bad experience, I've decided that the "best" way to avoid such problems in future is to provide a safe data access option. The alternatives is more people blaming me for their oversights, or disallowing control characters in user input.

Since what is best is a matter of opinion (everybody has different criteria) the only real way to determine what is best is to objectively look at the known facts.


Lots of lessons to learn from this.

There appears to be a lack of centralized project management. Features that are coded need to come from somewhere. They might be result of metrics, some formal specification, even an email from boss. Any feature impacts the project and allowing developers to add them ad-hoc without some process is a pretty strong managerial failure.

Simplest way to address such issues is to encourage adoption of tools like JIRA, PivotalTracker, Redmine, ... Even in a loose environment where everyone can contribute spontaneously, it allows for all team members to be informed of what is going on any why and gives a quick trail to originator in case of issues.

Alternate approach would be called agile. While it typically manages to avoid paper trail, it's based around one-click deployments, comprehensive test suites and live testing. Very usable with active user base or fairly big QA team. Such form of agile tends to produce poor results when delivery is only sporadic, since the features are constantly in motion. And even agile tends to rely on stories for prioritization, so all features must be suggested upfront, no one developer may implement out of scope.

There also appears to be a dire lack of knowledge sharing. People working in a team come from different backgrounds, have different skill sets and different levels of experience. While a staple of corporate development, CYA principle tends to be harmful over long run. It produces silos without raising the overall competence. Different techniques are used to address this, either short, weekly standup presentations on various concepts, small post-mortems on issues learned during last sprint, wikis containing various practices, perhaps automation of common processes shared across different groups.

Security is another issue. Security is a process. No amount of technical knowledge, effort or best practices will ensure it. While barriers may be raised, the most important aspect to address is how to react when security breach occurs. Will you even detect it? On web, there are many vectors of attack. In the given example, escaping/encoding issue was detected early during development, but general problem remain unsolved. If SQL injection is deemed an important aspect, then training should be organized for all developers and safeguards, perhaps via monitoring or daily log reviews should be put into place. Otherwise, contrary to intuition, this particular attack vector is not an issue to address. While obvious to someone who is familiar with it, there are many others.

On usability testing. Programmers are the worst possible choice of usability testers. There is also a term: programmer art, programmer UI. Unless same programmers are the end users, they should have nothing to do with usability. Many strategies exist how to approach this. In top-down development, functional specifications list set of requirements, QA verifies they are met. For live deployments, again metrics. For smaller projects, a client stakeholder is often chosen. An onsite representative provided by client who performs the testing and feature evaluation. The latter one is known to be problematic, especially if providing to a technically illiterate groups, who will struggle focusing on usability and often get distracted. The era or programmer testers has passed and isn't coming back, they simply aren't providing the right feedback.


But perhaps more importantly, all the issues mentioned have nothing to do with you in particular. They are exactly the type of organizational challenges one must face and will eventually learn through experience. The difficulties in software or product development are not technical, even though sometimes code may be involved.

#25 boolean   Members   -  Reputation: 1706

Posted 12 October 2011 - 05:52 PM

It's simple:

1) Hire someone who is useless
2) Try and maintain their mess as bug reports roll in
3) Swear to never name a variable "string1" or "frstNme" or "private int _GlobalRate" ever again
4) Lead by example.

I used to worry for the longest time that being self taught I would struggle in the real world, it's why I actually avoided the industry for a few years. Now that I'm in it all I can say is I've learned more in the last few years maintaining other peoples code than I ever did working on my own. Someone can explain until their blue in the face why an empty try catch statement is worse than not having one at all, but until you are tasked with looking through someone else's code for a magical hidden exception that is being thrown for 3 HOURS you will very quickly understand what "best practices" really are.

If you do not have someone else on the team, and I may be wrong saying this, but with nobody else around to require good code it's a bit of a lost cause. I'm quite proud of the code I write at work, but on my own projects at home it's a struggle to do things the 'right way' when I know I'll be the only one seeing it. I would recommend joining an open source project or starting your own, or do tutorials for GDnet, or blog posts with code snippets you are proud of. Something to get other peoples eyes on. Trust me, once you get those people looking at your code, you'll learn more about best practices than you ever wanted to.

[Android] Stupid Human Castles - If Tetris had monsters with powers and were attacking human castles. "4/5 - frandroid.com"

Full version and Demo Version available on the Android app store.


#26 speciesUnknown   Members   -  Reputation: 527

Posted 12 October 2011 - 10:36 PM


But there was a problem - I had decided that the user should be able to add any kind of data in the description of each to-do item. On my pages this was fine, but on the pages of the other two programmers, who were putting data right out of the DB and onto the page without htmlspecialchars() escaping, there were several script injection faults. The reason for this was the combination of two oversights; I had not considered the implications of allowing users to enter any data, because *my* pages were OK with this data; I had gone off and asked somebody more experienced how to support this safely. The other two guys had not considered the implications of dumping data right out of the database, because their input data did not allow html special chars.

The solution, which I have now learned to provide in future, is to provide a data access method along the lines of getPageSafeData() which performs all the page safe escaping for you. This way, next time I work with noobs, I can be sure my data isnt going to inject nasty things into their pages.


Honestly, reading this, you are all "noobs".
"I decided"... "they decided"... congrats you all failed Communication Skills 101.

There should have been no 'I' or 'they' in that, there should have been 'we' and you all should have decided on the right way to do things.

But don't worry, I've worked with people like you, deciding the 'right' way to do things without letting others who might need to know know... in fact I ran into that problem last week where, having communicated quite clearly with group leads over a couple of weeks that I was working on and changing file formats I came in one morning to discover one group had decided to change a file format without bothing to inform me.

So, complain about 'noobs' all you like but if you had all been following 'best practise' your problem might not have happened... and if you had talked and not just decided things on your own, well, same deal... but by all means, carry on in your little bubble where you are right :)


People like me? I accept that I made a mistake, choosing a more risky set of allowable data and not checking that my colleagues were able to handle it. I've taken a lesson away from this. We were all noobs - i was one of two interns, and the project lead was a PHD student who was new to project management.
Don't thank me, thank the moon's gravitation pull! Post in My Journal and help me to not procrastinate!

#27 Serapth   Crossbones+   -  Reputation: 5183

Posted 17 October 2011 - 11:27 AM



Look for another job. Find a company that doesn't interview you much about software development process.

TBH, I don't like companies that interview developers about software development process. It's completely irrelevant.


Depends on what you want to do... To be a great developer and an instrument of change in a company, you need to know what works and what doesn't. Especially if you're working at a company with a poor or absent SDLC policy. If you want to be just another cog in the machine cranking out code then sure... try to get a job at a big company where all you have to do is crank out another widget and let others worry about how to best get projects done.


As a self-improvement principle, then yes, you'd want to learn as much as you can to expand your knowledge and skill. However, most tech companies ask irrelevant questions to their interviewees just because they want the best candidate ever, regardless of what position they are looking to fill.

Successes of projects in a company depend on huge numbers of factors: CEO, management hierarchy, project managers, project executions, deadlines, visions, scopes, and many more. A single developer's vast knowledge about software development process won't have much impact on that. More likely he won't be put in charge to lead the project as his title is a "Software Developer" rather than a "Project Manager". Can he be outspoken and voice his concern and opinion what needs to be done during the course of a project? Sure, but whether he's going to be heard or fired depends entirely on the people running the company.


Truth is, big or small company, most software developers make shit people managers, so this is in fact a very good thing. After leaving games, I made a very lucrative career out of being a programmer with good people skills. At first I thought my success was a fluke and that "Gary the uber smart programmer guy" should have been the team/project leader, but as the years passed I did come to realize technically competent people that can actually lead ( it's like herding cats... ) other programmers while being able to talk to non-technical people are actually quite rare.

#28 Serapth   Crossbones+   -  Reputation: 5183

Posted 17 October 2011 - 11:33 AM


Needs must when the devil drives. Having had this bad experience, I've decided that the "best" way to avoid such problems in future is to provide a safe data access option. The alternatives is more people blaming me for their oversights, or disallowing control characters in user input.

Since what is best is a matter of opinion (everybody has different criteria) the only real way to determine what is best is to objectively look at the known facts.

Alternate approach would be called agile. While it typically manages to avoid paper trail, it's based around one-click deployments, comprehensive test suites and live testing. Very usable with active user base or fairly big QA team. Such form of agile tends to produce poor results when delivery is only sporadic, since the features are constantly in motion. And even agile tends to rely on stories for prioritization, so all features must be suggested upfront, no one developer may implement out of scope.


The problem with Agile in a corporate environment, is that you need to have an enthusiastic user base, which sadly is often not the case. The whole idea is rapid iterations based on user feedback, but if your users are unwilling, unable or slow giving feedback, Agile falls on its face. In a smaller environment, where many users wear many hats, this problem can be magnified even more! Another problem with Agile is, well frankly, decisions aren't always thought out as well as they should be.

Now if you have a dedicated QA department, Agile can work absolute wonders, but most people don't have a dedicated QA department.


Of all the different methodologies and techniques I have seen proposed, I had never seen one that comes close to a catch-all solution or that didn't have one major flaw. The only thing I can think of that I would universally recommend is pairs programming, watching paired programmings effect on your code base and turn around is simply amazing. Now that I work mostly by myself, I really miss having a partner; it both kept me honest and improved my code. Amazing part was, even when I was the senior and was paired with a junior programmer, it still had a positive effect on my code.

Actually, of all the roles or responsibilities I have had in my decade+ of professional programming, I think mentoring new developers was by far my favorite task. That I can to this day look the (very successful) careers of a half dozen people I mentored straight out of school fills me a fair bit of pride, more so than I have for any particular piece of code i've written! I guess that's why I spend so much time working on tutorials these days now that I am self employed.

#29 Antheus   Members   -  Reputation: 2393

Posted 17 October 2011 - 12:10 PM

The problem with Agile in a corporate environment, is that you need to have an enthusiastic user base, which sadly is often not the case.


Yes, that's "Agile". I specifically said "agile".

The whole idea is rapid iterations based on user feedback, but if your users are unwilling, unable or slow giving feedback, Agile falls on its face. In a smaller environment, where many users wear many hats, this problem can be magnified even more! Another problem with Agile is, well frankly, decisions aren't always thought out as well as they should be.


Agility is about quick turnaround and ability to respond to changes. It's accomplished by lowering barriers across all tiers. One of these may mean involving a client stakeholder. Who that is varies, so does their role. It's rarely the users, that's often counter-indicated, since many users will be simply too preoccupied with their actual work.

Some products and services were built using agile techniques based solely on metrics gathered from users. This is unrelated.

#30 JustChris   Members   -  Reputation: 149

Posted 18 October 2011 - 12:42 PM

There are some nice responses here. Even though they're not aimed at me, I learned a lot on what it is to work with a larger team.
But especially useful was Boolean's response, because I can relate to that one very well. I did a lot of work in fixing and reorganizing legacy code. I've started running a blog and posted a port of someone's older code on Github.

I think almost any company that gets several positive mentions on TechCrunch would have happy, enthusiastic developers and a good sense of how to handle projects. Otherwise, they wouldn't be able to grow as fast as they did. This is the kind of company that I'm aiming towards. I prefer working in a business where the software being made is the profit center and not a cost center that is delivered to an external client, like most "IT consultancies".

Having talked to someone that's been running his own web business for over 15 years, he says it makes sense, since the majority of the market are small customers and don't want uber-complex websites, companies can't justify bringing more than one developer for such work. As opposed to SaaS development, where they can afford giving more work since the software IS their main source of profit and can be as complex as they need.
Electronic Meteor - My experiences with XNA and game development

#31 Serapth   Crossbones+   -  Reputation: 5183

Posted 18 October 2011 - 01:10 PM

There are some nice responses here. Even though they're not aimed at me, I learned a lot on what it is to work with a larger team.
But especially useful was Boolean's response, because I can relate to that one very well. I did a lot of work in fixing and reorganizing legacy code. I've started running a blog and posted a port of someone's older code on Github.

I think almost any company that gets several positive mentions on TechCrunch would have happy, enthusiastic developers and a good sense of how to handle projects. Otherwise, they wouldn't be able to grow as fast as they did. This is the kind of company that I'm aiming towards. I prefer working in a business where the software being made is the profit center and not a cost center that is delivered to an external client, like most "IT consultancies".

Having talked to someone that's been running his own web business for over 15 years, he says it makes sense, since the majority of the market are small customers and don't want uber-complex websites, companies can't justify bringing more than one developer for such work. As opposed to SaaS development, where they can afford giving more work since the software IS their main source of profit and can be as complex as they need.


A friend of mine contracted himself as a fractional employee to small-medium businesses and it was pretty brilliant. Basically he took his 40 hour week and sold 1/4 alotments of his time to 5 different businesses ( yes, he over sold ). Basically each company paid about 1/4 the cost of a fulltime coder ( about 60K / 4 ) with a 25-50% premium, so 20-25K each and he guaranteed at least 10 hours a week, onsite if needed and had more hours available on a per hour basis.


So basically he was pulling down about 100K, while 5 companies that couldn't otherwise afford a fulltime developer got a good deal and a consistent face to call on, which is actually a really big deal. Also with the 5th company, it could result in a ton of overtime, although if you get lots of "over the 10 hour" weekly hours, you can make a serious bonus.


It's a pretty interesting and quite lucrative scenario, if you can come up with 4 or 5 contracts to work with, and can manage the overlap conflicts which no doubt arise.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS