Not to be too defeatist ...
... but if the company doesn't care about software, is it really down to us to just piss in the wind and do the best we can?
I've read answers here that mention convincing managment about the bottom line benefit of good software development practice, but when the boss won't even buy a 20 dollar book on the latest version of our chosen development platform, what else is there to do?
hello comrades! ;)
You could always get a new job.
Alternatively, if you want to keep your current job, you need to go to the management with a proposal which includes a budget request (for books etc...).
The IT department in your company has to treat itself as its own little mini-company.
Our role as developers is to support the core business functions of the business. No matter the field, we are capable of discerning what it is the business does. So ask questions, be involved in the accumulation of knowledge. Then sit back and see where technology can be a huge benefit. I would never shoot for the moon and convince someone outside the community about the latest and greatest software tools. All they need to know is how you can best serve them through facilitating change that will help with productivity and thus pad the bottom-line.
there are very good articles and stadistics that shows how the companies that invest on IT solutions gain advantage on those who not. you need to sell them the idea on how much they will save on implementing software solutions in the company
Generalities are impossible here. The company with the biggest development staff that I've worked for was a hospital. The audience for the software we wrote was perhaps a couple hundred doctors, if that, but nevertheless, the company did care about it.
Learn to speak their language. Your company does has a core business. Show how software and improve that business. That may mean selling more products or adding value (price) to the products they do sell. Instead of saying I need this book, say that we can improve the product by adding this feature which should result in this amount of extra income. Oh by the way we need these resources to make it happen.
I work at an environmental consultancy agency that happens to have its own software department. I don't think this is a bad situation because we have our users nearby and there are always enough people to test the software ;-).
Luckily we can buy our books and have great development machines. With two screens. So we might be a minority, at least they take us serious.
Well, there is this big thing called the Internet that almost all companies have that you can use to learn about software development practices. So the real question is, are you saying your software development skills and process are poor, and you are looking to improve them? If so, just get off your rear and do it!
Are you rather complaining about your co-workers development processes? Have you talked to them about their code? the answer of how to do good software development is all about process, and having good engineers. So you either improve process, or improve engineers. And good engineers tend to improve themselves. So again, what is your real question?
A good engineer will buy their own $20 book if they feel it will make them a better engineer.And then they will find a company that can afford to support the continuation of them becoming better engineers. IOW they engineer their careers as well.
software development in a company whose core business isn’t software?
It is called IT SUPPORT. That means any "software development" will be done in support of the company core business. It usually involve an IS (Information System), where the core business knowledge and value is processed.
I would argue that most major software development are done in companies whose core business IS NOT software! That is why the organisation of such enterprise implies strong business-oriented vertical lines, mixed with horizontal and transversal support lines, including IT, but also logistic, human resources, communications, asset group management, and so on.
By "IT support", I do not refer to "tech guys fixing computer or network", but I am referring to general Information Technology support of the OPERATIONAL side of the enterprise.
What is sometimes designated as 'OPER' is the "client" (internal client) of IT: the part of the company which may use computer, but which is more concerned about business activities (its core activity). So you have to sell your IT services to them within your enterprise.
What is interesting about this situation, is that it is not unique to your business, and happens all the time in software development firms as well. By the time you reach the top, it is rare, if ever, that management will sympathize because they have a business background and not a technology background. So you really have two choices:
You can find a job where you have someone else fight the good fight for you, which means a larger organization with a bit more red tape. Typically this comes in the form of a technology director, but you get an actual budget for things like training and books, and someone stands up for your department on your behalf.
Or, you can do the things you need to do to ensure a productive environment, which often times involves very little communication with upper management. You tell them what needs to happen and how it needs to be done. You don't ask, you tell them that "this is how things are done in software development". Don't be a jerk about it, but don't sugar coat it either. The reality is that most of the time they don't understand technology solutions, and are more attached to a budget. Don't give them the numbers first, but give them the ideology, and then tell them how much it costs. That really is the best you can do in a situation like this.
Ok, well, I am in the same position where I work. It is really uncanny how similar the situation you describe is to mine.
Now things I found that have helped me. They may or may not help you:
Management friendly diagrams (!) No I am not kidding. If you have a fancy idea (eg we recently implemented a json service so that distributers can embed stock data in their websites), all you need to do is draw it. I know that sounds insane, but it works remarkably well. This principle applies equally to tasks you are asked to perform, and in a normal situation you won't be able to implement it as well as you'd like (resources, time, etc), so draw it. I recommend Inkscape, with lots of gradients and shadows and futuristic-looking fonts. Use many buzz words.
Suck it in! Programming with infinite resources, infinite time, and infinite patience, with complete specifications would be so easy, it would be boring. Relish the challenge! "Yes so using client-side ssl certification is utterly wasted on this bunch of idiots, but who cares, let's do it."
Find a friend in the company who has clue and you respect. Use them to bounce ideas, help with little tasks, and most importantly, vent your rage about the imbeciles you are surrounded with. We have a sysadmin here, who has remarkable amounts of *nix clue, can't really program, but makes the perfect colleague.
While I haven't spent anytime as a developer in the private sector, I do have a couple years experience working as a developer in a university payroll office, where a similar mentality prevails. This wasn't even the job I was hired to do, but by actively making more own job more efficient through custom development I was able to present a compelling case for extending that model ("let the computer do the work for you") to other areas of the office. As of just a couple days ago, development now is my full-time job. I still don't get all the tools I would like to have or drive process in the way I would like to (and we certainly aren't selling software), but my point is that sometimes the best way to persuade management of a project's efficacy is to simply start small and let them see the benefits first-hand. I essentially automated a full-time job into a 0.25 FTE job. If you already have projects on your plate then it may require more creativity on your part, but I think the same sort of results-oriented mindset can be useful. Today when my office begins new project, its common-place for management to turn to me and say, "How can development help solve this problem?" That sort of attitude gives me a lot of room to say, "Sure, but let's approach this in the correct way."
Well, it doesn't sound as hopeless as it could be. Small encouragement eh? I worked at a company that wanted to take factory methodologies and apply them to coding. Didn't work too well.
Chances are the IT department is adding a lot of value to the business. But chances are that the business is in a competitive or low margin niche... so they will error on being stingy. In that scenario, you need to harness the stinginess (I hope you are a manager, or have the ear of your manager -- you'll need a good relationship with him/her to make this work). First, this may be unpopular, but give up on the idea of corporately sponsored training / conferences, or the like. At least for the next few years. Instead, do some research on the market. If there is a great salary discrepancy between you and the market, advocate to the manager for coordinated team education ... like sending them to a conference, but they go offsite for a week, and read a certain technology and discuss. Advocate this for two reasons:
1) Developers who receive training of some sort or who work on a team to improve their development system will be more productive -- and this is a low cost way to do it without adding expenses in a tight economy, and
2) This reduces the risk of attrition as it is good for morale.
A 3rd reason (but not one you want to mention) is that "absence makes the heart grow fonder" -- the absence of the development team for a short period of time will help everyone realize how critical they were to helping things run smoothly.
The other part ... I've had only one company of 3 or 4 buy me books. It is not a common practice in the world in general. Often a stingy boss will look at this and say: irrelevant expense. And a stingy boss who also values proactiveness will say: don't the good programmers take it upon themselves to study and learn? SO be careful how you word things to a manager.
One last thing: remember the rest of the company is your customer. Your job is to make them successful. Learn the business needs, learn to communicate with end users and stake holders. This will increase the perceived value and they will be more likely to help you in return. A good illustration of this (in fiction) is a Deep Space 9 episode: http://memory-alpha.org/en/wiki/Treachery%2C_Faith_and_the_Great_River_(episode) :-D
If you care about software development, move to a different company. My last programming job was in a business of about 50 people. I was one of 3 programmers who were stuck in the basement, literally. The core of the business was the software we worked on. We spent hours and hours writing documents and ROI papers just so we could get relatively inexpensive software upgrades. There were no QA people, no standardized testing procedures, unit testing, or decent issue tracking set up. I had a single monitor on an old original Pentium 4 with < 100 GB harddrive, and 512 MB of RAM. I did get them to upgrade the RAM, eventually, but the machine was still as slow as sin. We had single monitors because they didn't want the rest of the company to get jealous of the software team and they didn't want to buy everyone a second monitor.
Bottom line, if you have to fight tooth and nail to get approval from management for things like decent software tools, hardware upgrades, and standardization of the simplest standard processes like bug tracking, automated builds, etc, it's not worth it. If you really care about the company you work for, you may be able to initiate change. In my case, it was tough, as I was a "Junior Programmer."
As a member of the IT department, you have a primary responsibility to the business, and part of that responsibility is to help the business either save money or make money. There are plenty of examples where technology can in fact be a great boost to companies that are "software" companies. Efficiencies find their way into workflow software. Spreadsheets can become dashboards and web parts. Point your databases to spreadsheets and create a data mart. Have too many spreadsheets, consolidate and create a database.
Always be on the lookout for how the Internet can help communicate and maybe even save time. If you have many offices, demonstrate how collaboration software can save time and keep people organized.
All of the above represent opportunity that most companies offer. Have fun, and live life with courage as you become an asset to your firm.
It could be worse. Where I work any internal development is pretty much forbidden. An external product has to be found to for any problem, regardless of how specific the issue is, and regardless of how cheap it would be to produce internally by comparison.
This has two side-effects : one, most internal bespoke development that does take place is pretty terrible since there's no internal mechanism to peer-review/share best-practice/etc. two, almost all software projects are hugely expensive and late (coming from the same group of vendors who routinely fail to meet expectations). These problems are in turn seen as additional proof (if any were needed) for the need for big, professionally (i.e. externally) run systems/projects...
Said projects either fail a third of the way in (the budget exhausted at the pre-sales consultancy stage) or are eventually delivered, essentially highly specific solutions which combined the best of both worlds in that they are hugely expensive, unmaintainable, and where any licence will be both externally owned and highly restrictive.
Any development I therefore do is both clandestine and terrible.
Your best friend is your Business Analyst. Make friends with that person, and you're absolutely on the path to more respect. If there isn't a BA, well, there is, if you understand what I'm saying. Someone who is not doing the software is recognizing gaps in the IT infrastructure if you have a job at all.
My team (which has been me for the last month or so, but waxes and wanes over time) recently lost our long-term BA to another company with a need for the same kinds of business knowledge (engineering, in this case). Before he left, he was able to convince his superiors (who do not reside in the IT stack) that IT needed hardware and software resources well in excess of those provided to our internal clients by simple dint of the nature of our work requiring all the same resources "and then some".
I don't think it can be stressed enough: whoever you have access to in the wider business community, and in particular the people who provide you with whatever level of requirement or specification you use, you need to leverage them as advocates in the wider business. It may occasionally require an end-run around your management stack. Just stay calm, don't be disrespectful, and communicate the limitations you face as often as you can.
If you then discover that the limitations you face are also faced by everyone else in the business community, then it may well be time to find yourself a new position.
When the software isn't being sold, the development effort is part of what are called cost centers. For most businesses, it's an IT expense which is usually justified by the cost reduction benefits of automation.
When the software is being sold or empowers customer purchasing, the development effort is part of what are called profit centers. An Independent Software Vendor or on-line business are examples of such an organization.
The level of software quality and process maturity for profit center development is usually much higher than for cost center development. In cost center development, don't expect a lot of resource commitment from management. Take a look at eXtreme Programming as that is a formal process that targets cost center development.
As with any issue it comes down to project management. Consider these fun facts:
It is quite simple. If the software you are developing brings value to the business then it will be supported. If it doesn't bring value then you have to question why you are developing it. If you can show them how it will enhance their bottom line then this will be mutually beneficial to both of you and that way they will accept it into their business.
Get another job unless your happy to pick up the money!
And here is the logic. This is based on the assumption that you are a "good" developer and believe that you know the "right way" to build software....
The things you will be able to do:
Things that you are unlikely to be able to do:
Now I don't want to be defeatist but personally I believe this is the best case. Worst case is that you over elaborate, take on too much risk, try and be a "hero happens here" and poor performance ensues!