Programming sucks! Or something like that
I offer readers a translation of the article " Programming Sucks! Or At Least, It Ought To ", published in The Daily WTF. The publication talks about how an excess of professionalism in practice interferes with efficiency and is intended more for experienced developers than for beginners.
Programming is not fun. This is a tedious and boring task, and, of course, no feat. Whatever you do with it there, programming will definitely not be “sexy.”
I know what you think. Anyone who says that — and even more so writes this on blogs — needs to immediately deprive them of their programming license, take their keyboards away and put them on a microcomputer with CP / M, 8 "baud and a 1200 baud modem forever.
Of course, many of us, including me, like to write code. But should we like it?
')
Software developer is a unique profession in which we can use our skills, both for work and for hobbies. Unlike accountants, who are hardly in a hurry to go home to strike a balance in the family budget, many of us often tinker with a code of fun for fun and pleasure.
But in this article, let's try to focus on a kind of unaffected programmer and the work he does. In fact, let's narrow our scope even more and talk only about the developers of the “boring” software. By “boring,” I mean handling loading and unloading invoices, accounting for corporate fleet usage, generating expense reports, etc., and all this is for internal use only and with a huge pile of requirements specific to a particular company. So again, if you are not making a living with “boring” software, then this article is not fully applicable to you.
Although sometimes the line between “boring” and “sexy” software may blur, “sexy programs” are what we use regularly, every single day: SVN, Google Maps, Visual Studio, Firefox, etc. In fact, we, as programmers, rarely have to use some tedious software.
However, from the point of view of the development process , the picture is diametrically opposite. Only a select few are paid for developing “sexy programs,” while most of us are mired in the programming of a boring routine.
To define boring software there is a special term - “information systems”. And although the purpose of information systems varies from company to company, as well as specific requirements, by and large, they are all the same. They have a database that models the real world, rules that determine how data can change, an interface for working with the database, and a lot of different reports.
The formal process of creating these information systems first appeared in the 1960s, and since the 1970s, it has hardly changed at all ( Modern Structural Analysis is surprisingly still modern). In essence, you analyze the problem, map the data streams, structure these streams, create a database and write programs that are the interface for working with the database.
We have moved from “thin clients” in “green-eyed” terminals to “fat clients” in the form of PC applications. Then we went over to the “thin clients” on the web, and with platforms like the Windows Presentation Foundation, we will not have time to blink an eye how we will again find ourselves next to the “fat clients”. Anyway, our systems continue to do the same thing: writing / reading data.
The development of information systems has not changed much. It does not matter whether you use Visual Basic 3.0 or xHTML, the principles are almost the same: the database should be presented to the user's eyes in the most pleasant and friendly light. The code that is needed for this (and has always been necessary) is rather dull:
These five lines of code simply set some UI properties. Repeat this for each field, each entity, and then multiply by another 1.5, simply because some fields must be available from two different places. Now add all the code needed to validate and save the data obtained from the UI. If mathematics fails me, as a result, we get the fucking bitch of a dull, boring code.
“Despondency” and “boredom” are two words that do not really fit in with developers. We are a gathering of analysts who often have the education of a computer science (information technology) specialist. And we are capable of much more than line by line to reduce front-end with back-end. Perhaps we could facilitate our work using our skills and abilities.
This is where the snag lies. As Michael A. Jackson put it in his 1975 Program Design Principles, “Programmers ... often find salvation in their, in general, understandable, but in fact disastrous desire for complications and tricks in their work. Suspended from creating something more than just a program, they respond by making this program so sophisticated that it is a worthy challenge to their professional skills. ”
This 35-year-old observation day after day finds its confirmation here on The Daily WTF. The most sophisticated code and stories published here are generated by the developer to achieve mastery . These aspirations are in no way a kind of delusion or the result of malicious intent; they are instinctive.
When I wrote about soft-coding , I gave a fragment that most of the written code should look like, that is, the most specific code that implements the most specific business requirements. It's pretty boring:
Among the numerous reviews of this article, some offered rather funny feedbacks , demonstrating ways to “complicate” the code. And, unfortunately, these examples perfectly illustrate the implementation of simple business requirements that I have to face.
Other readers voiced several serious proposals for refactoring , which included all conceivable design patterns, interfaces, extensions, and other heaps of classes. Naturally, all this without a single glance at the module to which this hypothetical code applied, not to mention the general understanding of the system and the requirements for it.
There was even one guy, James Taylor, who essentially called me an idiot for suggesting that the developers would dirty their hands about some kind of business rules. Apparently, we all need to build outstanding expert systems with intricate UI interfaces that allow the end user to do all the dirty work.
Of course, those of us who live in the real world are aware that such “expert systems” exist only in the land of fairies, unicorns and lossless compression of random data . But there is another reality that many of us have to accept: application software development sucks, and no amount of XML or design patterns will change that.
It is not easy to accept the fact that the software that we write every single day, regardless of its purpose and purpose, is boring death. Manage magazine subscriptions. Medical bills reports. Property Registry Management. These are not programs that change the world. In fact, they are unlikely to even cause a smile on someone’s face. In practice, their true purpose is to increase the productivity of some workers.
However sad it may seem, our job is solely to bring profit to the employer, and not satisfaction to us. That is what it means to be a professional.
I am sure that many lawyers with burning eyes will cling to the first exciting trial, but will also quickly retreat if such a decision is the best way for the client. Architects dream of getting the opportunity a la Fallingwater , but if the project requires the construction of a large warehouse with unloading docks - it will be the only thing that they will put on the drawings. And if our employer needs software to manage payment vouchers, then he should get it, and not “a system based on plug-ins with scalable and real-time recognizable UI templates” or the need for something else we will convince ourselves.
It is useless to work with an uninspired, mediocre developer, but the other extreme — wrongly directed enthusiasm — is many times worse. A pair of bugs and a code that is difficult to maintain without tears, fade in comparison with the destructive results that the developer can lead to, motivated in the wrong direction.
Everything from the platform (" Let's try Ruby! "), Including the architecture (" yes, there cannot be only two levels ") and ending with the techniques that are directly used in the code (" we need an aspect-oriented framework! ") to be - and often it is - dictated more by the desire to explore a new technology, rather than the real needs of a business. Choose the wrong platform or invent the wrong technique, and the project is inevitably doomed.
Having signed a death sentence on more than one project, as a result of my desire to “compete” with myself, I had to master several important rules that should be followed when developing information business systems.
... and if nothing helps, ...
At the end of the day, the best programmers are not the ones who wrote the most amazingly elegant, breathtakingly innovative code. Real rock stars deliver projects before the target date and are cheaper than the allocated budget, and this is exactly what business needs. And these are exactly what we all should strive to become.
Programming is not fun. This is a tedious and boring task, and, of course, no feat. Whatever you do with it there, programming will definitely not be “sexy.”
I know what you think. Anyone who says that — and even more so writes this on blogs — needs to immediately deprive them of their programming license, take their keyboards away and put them on a microcomputer with CP / M, 8 "baud and a 1200 baud modem forever.
Of course, many of us, including me, like to write code. But should we like it?
')
Why do we write code?
Software developer is a unique profession in which we can use our skills, both for work and for hobbies. Unlike accountants, who are hardly in a hurry to go home to strike a balance in the family budget, many of us often tinker with a code of fun for fun and pleasure.
But in this article, let's try to focus on a kind of unaffected programmer and the work he does. In fact, let's narrow our scope even more and talk only about the developers of the “boring” software. By “boring,” I mean handling loading and unloading invoices, accounting for corporate fleet usage, generating expense reports, etc., and all this is for internal use only and with a huge pile of requirements specific to a particular company. So again, if you are not making a living with “boring” software, then this article is not fully applicable to you.
Although sometimes the line between “boring” and “sexy” software may blur, “sexy programs” are what we use regularly, every single day: SVN, Google Maps, Visual Studio, Firefox, etc. In fact, we, as programmers, rarely have to use some tedious software.
However, from the point of view of the development process , the picture is diametrically opposite. Only a select few are paid for developing “sexy programs,” while most of us are mired in the programming of a boring routine.
The Basics of Moody Software
To define boring software there is a special term - “information systems”. And although the purpose of information systems varies from company to company, as well as specific requirements, by and large, they are all the same. They have a database that models the real world, rules that determine how data can change, an interface for working with the database, and a lot of different reports.
The formal process of creating these information systems first appeared in the 1960s, and since the 1970s, it has hardly changed at all ( Modern Structural Analysis is surprisingly still modern). In essence, you analyze the problem, map the data streams, structure these streams, create a database and write programs that are the interface for working with the database.
We have moved from “thin clients” in “green-eyed” terminals to “fat clients” in the form of PC applications. Then we went over to the “thin clients” on the web, and with platforms like the Windows Presentation Foundation, we will not have time to blink an eye how we will again find ourselves next to the “fat clients”. Anyway, our systems continue to do the same thing: writing / reading data.
The development of information systems has not changed much. It does not matter whether you use Visual Basic 3.0 or xHTML, the principles are almost the same: the database should be presented to the user's eyes in the most pleasant and friendly light. The code that is needed for this (and has always been necessary) is rather dull:
txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;
These five lines of code simply set some UI properties. Repeat this for each field, each entity, and then multiply by another 1.5, simply because some fields must be available from two different places. Now add all the code needed to validate and save the data obtained from the UI. If mathematics fails me, as a result, we get the fucking bitch of a dull, boring code.
Developer Dilemma
“Despondency” and “boredom” are two words that do not really fit in with developers. We are a gathering of analysts who often have the education of a computer science (information technology) specialist. And we are capable of much more than line by line to reduce front-end with back-end. Perhaps we could facilitate our work using our skills and abilities.
This is where the snag lies. As Michael A. Jackson put it in his 1975 Program Design Principles, “Programmers ... often find salvation in their, in general, understandable, but in fact disastrous desire for complications and tricks in their work. Suspended from creating something more than just a program, they respond by making this program so sophisticated that it is a worthy challenge to their professional skills. ”
This 35-year-old observation day after day finds its confirmation here on The Daily WTF. The most sophisticated code and stories published here are generated by the developer to achieve mastery . These aspirations are in no way a kind of delusion or the result of malicious intent; they are instinctive.
When I wrote about soft-coding , I gave a fragment that most of the written code should look like, that is, the most specific code that implements the most specific business requirements. It's pretty boring:
private void attachSupplementalDocuments()
{
if (stateCode == "AZ" || stateCode == "TX") {
//SR008-04X/I are always required in these states
attachDocument("SR008-04X");
attachDocument("SR008-04XI");
}
if (ledgerAmnt >= 500000) {
//Ledger of 500K or more requires AUTHLDG-1A
attachDocument("AUTHLDG-1A");
}
if (coInsuredCount >= 5 && orgStatusCode != "CORP") {
//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
attachDocument("AUTHCNS-1A");
}
}
Among the numerous reviews of this article, some offered rather funny feedbacks , demonstrating ways to “complicate” the code. And, unfortunately, these examples perfectly illustrate the implementation of simple business requirements that I have to face.
Other readers voiced several serious proposals for refactoring , which included all conceivable design patterns, interfaces, extensions, and other heaps of classes. Naturally, all this without a single glance at the module to which this hypothetical code applied, not to mention the general understanding of the system and the requirements for it.
There was even one guy, James Taylor, who essentially called me an idiot for suggesting that the developers would dirty their hands about some kind of business rules. Apparently, we all need to build outstanding expert systems with intricate UI interfaces that allow the end user to do all the dirty work.
Of course, those of us who live in the real world are aware that such “expert systems” exist only in the land of fairies, unicorns and lossless compression of random data . But there is another reality that many of us have to accept: application software development sucks, and no amount of XML or design patterns will change that.
Just accept it
It is not easy to accept the fact that the software that we write every single day, regardless of its purpose and purpose, is boring death. Manage magazine subscriptions. Medical bills reports. Property Registry Management. These are not programs that change the world. In fact, they are unlikely to even cause a smile on someone’s face. In practice, their true purpose is to increase the productivity of some workers.
However sad it may seem, our job is solely to bring profit to the employer, and not satisfaction to us. That is what it means to be a professional.
I am sure that many lawyers with burning eyes will cling to the first exciting trial, but will also quickly retreat if such a decision is the best way for the client. Architects dream of getting the opportunity a la Fallingwater , but if the project requires the construction of a large warehouse with unloading docks - it will be the only thing that they will put on the drawings. And if our employer needs software to manage payment vouchers, then he should get it, and not “a system based on plug-ins with scalable and real-time recognizable UI templates” or the need for something else we will convince ourselves.
Rethinking Software Development
It is useless to work with an uninspired, mediocre developer, but the other extreme — wrongly directed enthusiasm — is many times worse. A pair of bugs and a code that is difficult to maintain without tears, fade in comparison with the destructive results that the developer can lead to, motivated in the wrong direction.
Everything from the platform (" Let's try Ruby! "), Including the architecture (" yes, there cannot be only two levels ") and ending with the techniques that are directly used in the code (" we need an aspect-oriented framework! ") to be - and often it is - dictated more by the desire to explore a new technology, rather than the real needs of a business. Choose the wrong platform or invent the wrong technique, and the project is inevitably doomed.
Having signed a death sentence on more than one project, as a result of my desire to “compete” with myself, I had to master several important rules that should be followed when developing information business systems.
1. Learn business.
It is ridiculous to assume that there is absolutely no need to understand the essence of the business when developing software for this business. Without understanding the true needs of the customer it is impossible to provide him with what he really needs. True, when they say “new database for every day”, they do not really mean a new database every day .2. Serve the interests of the business.
Every artisan wants to use the latest, gorgeous and powerful tools, but they are rarely needed for work. Likewise, it is almost never possible to instantly update platforms / libraries / languages. That 10-year-old code written in “classic ASP” is not out of date - it’s just not so fun to accompany.3. Learn outside of work.
Self-development is the main principle of any profession, but it should be done “outside of work”, that is, not during the development of information systems. Instead, learn by creating applications for yourself, your team, or even for some open source projects. Explanation: “Outside of work” does not mean that you should not learn at all in the process of working. Training is important, but do not engage them in the development of information systems for the customer. Save it for your own or team-based projects.4. Encode mainly business logic.
If, for the most part, the code written by your hands is not specific to the domain and is not related to the objectives of the application, it means that you are using the wrong tools. If you firmly believe that the system needs a framework for logging, then voice it and get customer approval.5. Do not get bored.
No O / R-mappers or code generators can save you from the fact that records, fields, validators, etc. must be registered manually in at least two places (front end and back end). And the UI generated from the base is as bad as the base generated from the UI.6. Look for satisfaction everywhere.
If your only source of pleasure is to write complex code, then you will never be a good and satisfied application developer. Personally, I am happy with the thought that I helped the end user to increase his productivity and / or opened up new opportunities for some organization.... and if nothing helps, ...
7. Find yourself another job.
You may have reached your maximum in this job. Or maybe you just get sick of this type of programming. Anyway, there is a whole mass of programmatic capabilities that do not include boredom and information systems. Of course, the competition will be much higher, since masterpieces like “The Brilliant Paula's bean” are born only in the depths of IT corporations.At the end of the day, the best programmers are not the ones who wrote the most amazingly elegant, breathtakingly innovative code. Real rock stars deliver projects before the target date and are cheaper than the allocated budget, and this is exactly what business needs. And these are exactly what we all should strive to become.
Source: https://habr.com/ru/post/52490/
All Articles