Jump to content

Are info. technology folks the new cowboys of the century?


shootingstar

Recommended Posts

I get this powerful impression full time, long term IT folks aren't really good on consistent documentation long term.  After a major project is over, their inclination (if they had any in the first place), is the technical documentation slowly erodes ...meaning doesn't include revisions nor all the parts with other IT applications /groups for a software application that consists of integrating of 2-3 major enterprise wide software applications.

Are the tech. cowboys just a few who are terribly conscientious in their documentation long-term to manage risk to their own employers/organizations?

Link to comment
Share on other sites

There is very little documentation with the IT dept.  I have 4 different programs that are critical to our business operations and I deal with out IT and the vendors to keep them running.  My vendors have in depth manuals but my IT doesn’t document anything.  

I have to watch what they do & take note or call them back.

Link to comment
Share on other sites

28 minutes ago, ChrisL said:

There is very little documentation with the IT dept.  I have 4 different programs that are critical to our business operations and I deal with out IT and the vendors to keep them running.  My vendors have in depth manuals but my IT doesn’t document anything.  

I have to watch what they do & take note or call them back.

This is one of the reasons I have very little trust in cryptocurrency which wouldn't even exist in the first place without computer technology...and as the world moves increasingly towards artificial intelligence....ok are those algorithms being documented well with enough people to solve/disentangle more complex problems/inaccuracies in automated complex calculations?  For the long term, with many changes in IT staffing. and loss of knowledge/no knowledge transfer?

Our enterprise wide software application is not even on the critical software infrastructure list for our organization for immediate disaster recovery.  It's pretty shocking....considering the fact there are 17 million records and the application has at least 25  different designs that integrate in terms of workflows, other automated processes with 4-5 other different internal enterprise software applications.  

 

 

Link to comment
Share on other sites

Documentation often gets the lowest priority for several reasons:

1.  You have to get it working first.

2.  Specs change rapidly, requiring changes in the software and later documentation.

3.  Once you get it running, there is always a new project that needs you attention immediately.

4.  No one ever reads the documentation anyway.  Most documentation that does get done is meant for the IT personnel who have to maintain the system.

 

  • Heart 1
  • Awesome 1
Link to comment
Share on other sites

When I was involved in software design for the P&W aircraft engine test cells I was warned by a long time data guy that I was creating a system with documentation good enough that others could easily follow my work and that wasn't standard in the industry for protecting one's job.  My opinion was that I wanted a repair tech to be able to easily troubleshoot a problem in the cell at midnight and return the system to operating condition stat.

I was warned.  After the system was up and operating for a while with very few problems I was laid off.

Myth and magic and a cloudy curtain over on'es work is job security for IT guys.  Companies do that sort of thing often enough for the community to have been forced to learn how to protect themselves.  Not all companies though.

  • Heart 1
  • Awesome 1
Link to comment
Share on other sites

I have been in the IT industry just over 35 years.  The only documentation an app dev person creates they have been forced to write by management.  Folks in IT want to document using crayons and single syllable words.  I know, I’ve been one.

There are cowboys in IT but documentation has nothing to do with it.  See @jdc2000‘s post above.

Link to comment
Share on other sites

8 hours ago, shootingstar said:

and as the world moves increasingly towards artificial intelligence....ok are those algorithms being documented well with enough people to solve/disentangle more complex problems/inaccuracies in automated complex calculations?

I'm in the AI/ML field right now. To answer some of what you mentioned: Yes and No.

In several fields where ML is being deployed; banking, finance, insurance, and healthcare to name a few, are very regulated on the structure and repeat-ability of the algorithms. FOr obvious reasons we want to know how the program came to those results so we can fine-tune, manipulate the now built model to fit other circumstances and in federal space, make sure the process isn't discriminatory in some way.

While there are other areas: neural nets, black boxes, deep learning structures that you can document the entire process of how you built it but as soon as you run your first data source through it you have no idea the structure anymore. These are for mostly academic research but there are plenty of areas where it is deployed actively. I was part of a group, my company was the core provider of the data pipeline and model build, to create a series of black-boxes ( hopfield network that then back fed certain results to a convolutional neural network) to eliminate the need for credit reporting and gave a more accurate PLV (potential lifetime value) for insurers. Once we built the models and trained on the origin data; 6 million insurers, we couldn't even recognize how the algorithms were structured and how it attributed weights/measures. We ended up with something that is currently live and deciding the type of rates on home/medical/business insurance for a very large national brand. 

In my line documentation is key. We use it for our entire process. We even have ML tools that auto create proper data dictionaries, proper data management is core to our capabilities and our business. Others are considerably more cavalier. A lot of our clients come to us with multiple systems across their entire enterprise and there is no data unification. Redundant, poorly organized file structures in half a dozen (or more) systems all not talking to each other. My job it to create that unified data model, get everything into a single place and talking to each other. Reporting, analytics, predicive capabilities is what everyone comes to us for but in reality their first step is cleaning up their mess. We charge handsomely to do it.

Link to comment
Share on other sites

6 hours ago, jdc2000 said:

Documentation often gets the lowest priority for several reasons:

1.  You have to get it working first.

2.  Specs change rapidly, requiring changes in the software and later documentation.

3.  Once you get it running, there is always a new project that needs you attention immediately.

4.  No one ever reads the documentation anyway.  Most documentation that does get done is meant for the IT personnel who have to maintain the system.

 

Good list. I'll add this:

5. Management doesn't pay for documentation to be completed.

This is really part of #3 as most projects are late and over budget. Once you get things mostly running, management declares victory and moves on to the next project.  

Link to comment
Share on other sites

3 hours ago, maddmaxx said:

When I was involved in software design for the P&W aircraft engine test cells I was warned by a long time data guy that I was creating a system with documentation good enough that others could easily follow my work and that wasn't standard in the industry for protecting one's job. 

I've always said that I would be the easiest person to lay off as I document my job very well. I have a 75 page document that says what to do daily, weekly, monthly, and annually. Plus a lot of info on issues I've seen in the past and how to fix them. The only problem they would have getting rid of me is that they can't find anyone to do my job. Until recently there were 6 positions with only 2 of use filling them. 

Link to comment
Share on other sites

1 hour ago, donkpow said:

IT professionals give cowboys a bad name.

Once a continental market was established, the country started working on developing the trans-continental railroad. Cowboys were only around as long as it took to get the trains rolling, and that didn't take a long time.

Cowboys were itinerant farm workers. We've never held itinerant farm workers in high regard. The reason for that discrepancy is simple enough, we've woven a mythology around those particular farm workers. Then and now, farm workers were often treated poorly. Funny how the myth never goes there.

1/3 of them were Black. The values we attribute to those cowboys in our national mythology were actually the values of the Plains Indians, speaking of treating people poorly...

 

  • Confused 1
Link to comment
Share on other sites

Documenting things requires so much time when it involves programming and that increases as available memory increases.

When I wrote the world's first animated computer adventure game in 1981, Castles of Darkness (you can find me on the Giant List of Classic Game Programmers, https://dadgum.com/giantlist/) written for the Apple II, I used an artist's sketch pad, about 2' x 3' to put the main flowchart together and then additional sheets to expand on key sections.  And all that was for a binary coded program that fit on just a 144K, 5.25" floppy disk!

Today's programs are so large that huge canned subroutines, whose potential problems the programmers don't even know about, are purchased to allow the programs to be completed in a reasonable time.

Link to comment
Share on other sites

8 hours ago, jdc2000 said:

Documentation often gets the lowest priority for several reasons:

1.  You have to get it working first.

2.  Specs change rapidly, requiring changes in the software and later documentation.

3.  Once you get it running, there is always a new project that needs you attention immediately.

4.  No one ever reads the documentation anyway.  Most documentation that does get done is meant for the IT personnel who have to maintain the system.

 

Yeah our IT guys are the same, a lot of truth here.

Our IT guys don’t wear cowboy hats though, do you!?!?

  • Haha 1
Link to comment
Share on other sites

12 hours ago, shootingstar said:

I get this powerful impression full time, long term IT folks aren't really good on consistent documentation long term.  After a major project is over, their inclination (if they had any in the first place), is the technical documentation slowly erodes ...meaning doesn't include revisions nor all the parts with other IT applications /groups for a software application that consists of integrating of 2-3 major enterprise wide software applications.

Are the tech. cowboys just a few who are terribly conscientious in their documentation long-term to manage risk to their own employers/organizations?

Not the tech guy's role or responsibility.  It is the management needing to kick their tech WRITERS into gear.  Documentation definitely should NOT fall on an engineer's shoulders. Sure, they are part of the process - especially for new development - but it's the role of the document writers to step up and make the docs that are required.  If your PM doesn't include the documentation team throughout the process - including past the "completion" of coding and testing - they are doing it wrong. 

Link to comment
Share on other sites

3 minutes ago, Razors Edge said:

Not the tech guy's role or responsibility.  It is the management needing to kick their tech WRITERS into gear.  Documentation definitely should NOT fall on an engineer's shoulders. Sure, they are part of the process - especially for new development - but it's the role of the document writers to step up and make the docs that are required.  If your PM doesn't include the documentation team throughout the process - including past the "completion" of coding and testing - they are doing it wrong. 

Is this the new millennial approach?  Documentation team?  Wholy carp.

  • Haha 1
Link to comment
Share on other sites

8 hours ago, late said:

Once a continental market was established, the country started working on developing the trans-continental railroad. Cowboys were only around as long as it took to get the trains rolling, and that didn't take a long time.

Cowboys were itinerant farm workers. We've never held itinerant farm workers in high regard. The reason for that discrepancy is simple enough, we've woven a mythology around those particular farm workers. Then and now, farm workers were often treated poorly. Funny how the myth never goes there.

1/3 of them were Black. The values we attribute to those cowboys in our national mythology were actually the values of the Plains Indians, speaking of treating people poorly...

 

Right. IT workers gave them a bad rap then, too.

Link to comment
Share on other sites

18 hours ago, jdc2000 said:

Documentation often gets the lowest priority for several reasons:

1.  You have to get it working first.

2.  Specs change rapidly, requiring changes in the software and later documentation.

3.  Once you get it running, there is always a new project that needs you attention immediately.

4.  No one ever reads the documentation anyway.  Most documentation that does get done is meant for the IT personnel who have to maintain the system.

 

#4. Of course for IT and their supervisors to read when the time comes and when there's multiple integrations with 1 major enterprise software platform all created at different times by different teams with a major software upgrade that will also hit all the integrations.

12 hours ago, goldendesign said:

I'm in the AI/ML field right now. To answer some of what you mentioned: Yes and No......………………….

In my line documentation is key. We use it for our entire process. We even have ML tools that auto create proper data dictionaries, proper data management is core to our capabilities and our business. Others are considerably more cavalier. A lot of our clients come to us with multiple systems across their entire enterprise and there is no data unification. Redundant, poorly organized file structures in half a dozen (or more) systems all not talking to each other. My job it to create that unified data model, get everything into a single place and talking to each other. Reporting, analytics, predicive capabilities is what everyone comes to us for but in reality their first step is cleaning up their mess. We charge handsomely to do it. 

Ok let's put it this way:  critical GIS mapped infrastructure, financial records, HR, law, etc.  …  Unified data model would have to be mapped or at least isolated in their own box without touching another application build.

Link to comment
Share on other sites

On 6/14/2019 at 1:58 AM, jdc2000 said:

Documentation often gets the lowest priority for several reasons:

1.  You have to get it working first.

2.  Specs change rapidly, requiring changes in the software and later documentation.

3.  Once you get it running, there is always a new project that needs you attention immediately.

4.  No one ever reads the documentation anyway.  Most documentation that does get done is meant for the IT personnel who have to maintain the system.

 

And if you use consultants, documentation is billable.

Documentation isn't glamorous and the people paying the bills, would rather pay for horribly written code and infrastructure.  

Out of all my years of consulting, most CTOs paying the bill, complain about paying for documentation.  The information in documentation is just as valuable as normal billable work but, short sided thinking from CTOs usually takes over in the line of work I do.  The project deadline is more important and the immediate ROI takes over the focus of the project.  CTOs have to answer to CIOs and CFOs and my schizophrenic chicken scratch isn't a valued line item.

I can document like a mofo though.  But you usually need a crazy person to interpret it (or someone from IT).

Shu Fang  

Link to comment
Share on other sites

The most successful software program I ever worked on was built around proper documentation being job 1.  The jet engine test cells at Pratt and Whitney were operating although no one really understood how.  The program that ran them was written by one man who never documented a single thing.  What's more his coding looked like the worst spaghetti code ever written by a college freshman learning basic.

The task was to deconstruct the code that operated the test cells and rewrite it in a form that humans could work with when things went wrong.  I had more "fun" that year than any other in my career and in the end we had a readable, subroutine organized program that was integrated with the 150 or so E sized electrical prints that showed the electronics of the cells along with a section of documentation for each subroutine that explained how things worked when they were working well and a full diagnostic program that ran on a laptop plugged into various ports in the cell so that folks could walk into a problem and determine what was not happening relatively easily.

The key was that the documentation went first.  Before good code could be written, someone had to describe what it had to do and how it had to work.  Prior to that in the early 90's it was more common for engineers to dive in and begin writing code without defining the problem.  It was not unusual to find that an error created by bad code had a patch that undid the result instead of being replaced by good code.

  • Awesome 1
Link to comment
Share on other sites

4 hours ago, Shu Fang said:

Out of all my years of consulting, most CTOs paying the bill, complain about paying for documentation.  The information in documentation is just as valuable as normal billable work but, short sided thinking from CTOs usually takes over in the line of work I do.  The project deadline is more important and the immediate ROI takes over the focus of the project.  CTOs have to answer to CIOs and CFOs and my schizophrenic chicken scratch isn't a valued line item.

Totally agree.  The senior cowboys want to look like victors at project end. Sustainment is given to others lower down the food chain or those still scrambling around daily with client operational problems.

I'm certain some yahoos in our organization STILL have not laid out on spreadsheet matrix which People, ArcGIS, Oracle, CRM, several custom bulk loaders, POSSE workflow and then other vendor specific workflows flow in and out /integrated into our mother software platform where we have the content...that goes to court/freedom of info. , or ..some accessible to public, etc.

My boss is deliberately placing a wall around our group so we're not held responsible for lack of technical documentation....for other software that's not our area of expertise nor technical uber solvers.  We document on business needs, solution requirements and managing the content itself once it lands into the mother enterprise system.

Link to comment
Share on other sites

12 minutes ago, wilbur said:

If I have to read directions, the IT guys didn’t design it right, dammit!

For many things this is indeed true.  If you have a switch that shouldn't be turned on, then the software shouldn't let it turn on.  You have to protect yourself from user indifference.

  • Heart 1
Link to comment
Share on other sites

42 minutes ago, wilbur said:

If I have to read directions, the IT guys didn’t design it right, dammit!

So on our platform we have a fairly decent amount of documentation on features. Most of our user base is business level or "analyst". 

For giggles we put in a button on the visual studio, think tableau or powerbi, of our platform a "beautify" button. It takes their color palette and shifts it randomly one color selection over. We never documented it nor told  them about it in the release notes. It's now one of the most clicked item in that app. We even got a positive mention on one of the review sites.

Makes us laugh more than we should.

  • Heart 2
Link to comment
Share on other sites

54 minutes ago, wilbur said:

If I have to read directions, the IT guys didn’t design it right, dammit!

We used to used a product that had horrible performance problems, and it later improved a lot, and I'll never forget the salesman's offhand quip: "We find when it works well we get a lot fewer questions about its internal workings." :D I never really liked that salesman until he demonstrated a sense of humour with that gem. :D

 

 

  • Heart 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...