Even if it's like comparing potatoes with tomatoes I'd like to share my thoughts about it, would you mind ?
What we always laughed about OS
- the blue/gray screen with an incomprehensible error message
- the Message Box with some rant about some memory address failure
- the unresponsive OS due some broken application able to make everything else stuck regardless the number of CPU and thread the OS can handle
- the "quit program" explicit action that does not quit the program
- any sort of security issue
- the change/update that requires a system reboot
What we are always "scared about" online
- the white screen due some JS/CSS failure for the current browser
- the forgotten alert or console.log inside some try catch with some rant about generic error message (or even worst, the unmanaged error)
- the unresponsive DOM/web page due some broken piece of JavaScript able to make everything else stuck regardless the number of CPU and WebWorkers the Browser can handle
- the "close window/tab" explicit action that takes ages due some greedy onunload operation
- any sort of security issue
- the change/update that requires a page reload
We are all in the same field
Architecture matters, experience matters, performances matter, investigations matter, code quality matter, unit tests matter, UX is essential, and UI only attractive.This is the software development world, no matters which language, no matters which customer, no matters which company ... isn't it? So why things keep being the same in every software field ?
Delivery, delivery, delivery !
The main reason many applications out there, web or not, will rarely be that good.The scrum purpose is to make theoretically well organized baby steps and the agile often utopia due constant, drastic, changes you may want to face during an already planned task while you are implementing the task itself.
The time ? The worst enemy when it comes to quality. As I wrote in September 2009 we are loosing software quality due temporary solutions that last forever, decisions made without real world use cases to consider and everything else web developers are complaining, as example, about W3C decisions.
Is W3C that bad ? I think it's great, and I think we should all appreciate the Open Source effort we can read, support, or comment, on daily basis as is for JavaScript future if you are tough enough to face people proud by default about their decisions ... they can understand, they can change their mind.
The direction ?
Too much new stuff in too short time that could imply future problems when it comes to maintainability and backward compatibility, the day somebody will realize: "something went terribly wrong here!"The legacy code that blocks improvements, the country or corporates stuck behind old, deprecated, un-secure, old pseudo standard that are causing them more damage than saving.
Is everything going to produce cheap with screwed up quality? Well, this is apparently the tendency about clothes, cars, and something I always wondered about: if your Master/Phd is from the most expensive and qualified institute in this world, how would you feel to work underpaid in some emerging country able to provide everything you have been instructed for in 1/10 of your salary and with much higher units per months ?
Either that institute won't be worth it anymore, or you gonna feel like everything you learned did not really make sense.
This is a potential side effect of out sourcing too, the cheap alternative to a problem that many times is not truly solved, simply delegated and delivered with lower quality but respecting, most of the time, the deadline that once published will make max 70% of customers happy, loosing 30% until they'll face same problems with next "brand" they decide to follow.
Dedicated to
All those persons out there that do their best in daily basis believing in their job, whatever it is.All those persons underpaid still able to put best effort and provide results regardless the country/economy situation.
All those workers that would like to have more time to do things better, and all those Open Sources/Standards Maker that should be more distant from this frenetic delivery concept, and a bit more focused on doing things properly and able to last much longer ... we would not need so many changes, software speaking, if things were already great and this is what I have always tried to do with all my old projects, often forgotten, still working after 5 or more years of untouched code, and under newer versions of the same programming language.
I had more time back at that time, and things are still working.
I am missing products like the original Vespa, out of Italian company that can still run in your city street and with 30 years on its shoulder: can your cheap scooter, software, architectural decision, do the same?
Quality is not built-in where you are...
ReplyDeleteIf you remember me working there, you saw a bunch of books, the top one from 1971, still holding (it's Dijsktra's Structural Programming, of which most of it was about quality and why it matters), you saw a lot of documentations, and very integrated care was taken at every step, that user needs are adressed and met.
Or you can ask your (former ?) boss: as a west german, he did everything he could at his former position in the company for quality: maybe the phones he created there do still run in someone's hands. Today's handsets? By looking at the N9, I don't give it a month to endure, simply casing-wise.
But that's fine, the phones of the 2000s were meant to be thrown away, just like the code you write: it's to support today's needs, to support all the stakeholders, of which end-users are only one: your teammates, the salary of all the employees, the positions, the career paths also do matter. It's to support quick move-on, so we can join the next bandwagon more quickly. You're there because they wanted to join the HTML5 Mobile bandwagon.
I still miss the old methods: how products were meant to endure in the RUP times when I was taught as a software engineer, how we did carefully craft the documentation, create handover and deployment packages (I did this time too! There was even a mail at each of my product owner, titled, 'in case I'm shot by a car or fired on short notice'), and carefully crafted each step, planning in advance, knowing what we know, and knowing what we don't know in advance, before writing a single line of code, documentation, unit test.
Also, in RUP, in 4+1, everything was centered around use cases, what benefit would it bring for users in their real life. I've seen some post-its you've seen, laughable. I've left the project you were in when I was in when I realized the guy who dreamed it did dream about the hills, but not about why would it be useful to see them.
None of this mattered. The architecture wasn't respected, the implementation hadn't gone the way I told them in the form of pattern-solution howto, why things shall be that way, the PO forgot that there was an email anytime. It just doesn't matter. Move on, quickly. If we don't find out, we throw it out. Rewrite.
I think I've left when I realized that the stakeholders aren't about users: I left mentally when I realized that the stakeholders are the exact employees that I wanted to keep the system safe from: the young PO who doesn't know anything about project management, and was born in a very different mindset; the stupid programmer who has to survive in order to support his kids, and that's the only thing he's living for; the team, which made commitment for itself; the UX designers who were trying to hide the fact that sometimes they have no idea what's going on. People who just want to have a job as long as it lasts, and managers who want to give breads out to anyone who's asking, as long as it lasts. This doesn't have to bring out a working product, nobody is interested primarily in that. If it works, fine, but we have more important things to care about.
I'm committed to the users; that their problems will be solved, no matter what architecture, organization, etc is around. I'm committed to understanding as a basis of consistence, that each of the steps are a logical result of how problems are to be solved. I just couldn't commit myself to pure survival as well.
Once you commit yourself to the users, there are no more popups, console.logs and so on. Once you design on paper what you do beforehand, unit tests are simply not needed. Once you have something, which is so pure, that it's the exact opposite of the problem it tries to solve, it will endure.
Or it won't, but the world is not about understanding now; it's about surviving. just move on, try to survive.
Aadaam no software company is perfect and all we can do is to underly problems and avoid, if it's possible, to give up.
ReplyDeleteYour contribute has been recognized and appreciated but it's kinda obvious to me you suffered a moment of changes with not enough time to spread properly your ideas, ideal, or solutions.
You were in a team, I am in another one, and things may be different situation per situation but I agree that work to survive or work for the paycheck cannot bring much innovation, reasonable choices, or product of the year awards.
I still "fight" on daily basis to do my best respecting my role and the role of people beside me and I am pretty sure that if they do their best too, cool things may come out and I do believe, these things, are coming out indeed, at least where I am right now, and hopefully able to last long and grow up accordingly with what's truly needed and not invented uses cases.
I hope you are still doing your best where you are now, and I hope you'll never give up.
The risk is that you are going to survive too if you cannot adapt yourself in a way that can only, and of course hopefully, bring advantages for both you and the product you are following at that time.
Hope to meet you in JSConf.EU man!
Nah, I still didn't join any other venture so far, I was shaking in shock for months after how terrible that place was. I collected my CV about 2-3 weeks ago, but so far ConSol didn't make me an offer and I was lazy to send it around.
ReplyDeleteI won't go to JSConf, when I realized it'll be, it was already sold out, besides... what do those people talk about?
I'm lurking on forums just to shock myself with the current state of software development...
One guy asked "why do customers always demand schedules and cost approximations when we will be late anyway always" (you shouldn't be late, if I can calculate with +-10 percent, you can do that too)
The other, a book writer, said, at day one of a project you should have your production deployment system ready, able to deploy with zero features (huh? I thought we're to solve real needs, not technical problems)
Same bookwriter told a story when 80 developers didn't start the program itself, just the unit tests (and automated acceptance) of their modules and it was broken for 3 weeks, and this turned out only on staging at release, they solved it by adding a new test to test existence of HTML body (do you have a soul? how could any of those 80 sleep that week, after they knowingly tried to give out something from their hands for humans to solve human needs, not seen by their own human eye before at least once?)
All lean startup guys say that you shouldn't have assumption on user needs and behaviour (hence no models for that), you should test on real users on production (huh? when it works, it's brilliant, but when it doesn't, you just gave your users sh.t and they can't solve their problems; also, you invested full-cost for some sh.t, you simply won't throw it out as it's expensive - how many times I've seen that with a-product-not-to-be-named?)
And of course, the usual "If agile doesn't work in your enterprise, you aren't agile enough". I firmly believe that N is Agile enough, and the fact that its demise started the same time they switched to Agile is anything but a coincidence.
In this situation, shall I care wether it's DOJO or jQuery? Shall I go to a talk when it's titled "Client Side Frameworks Suck", which implies the guy doesn't understand what the framework pattern is and what it is for?
Shall I go and see BG talking about getting better, when the module he wrote literally degraded with each release in every sense while I was there? Oh yes, he's a great TDD guy, he's doing his best, except he choose his values in a way that getting better for him seems to make the products worse for me.
No, this won't change. Not unless we start to say, that "I do my best but X and Y doesn't!" Or at least we say that our values seem not to bring benefits for the user, it's solely for the benefit of us.
Never forget, that when you're in a war, the soldier fighting against you is also doing his best; this doesn't mean it's benefical for the things you believe in at all.
I believe that at one point a professional should give up, saying it won't be better. A professional shouldn't have flexible values, leave those for politicians and other cowards. When I say I'm in for the users, I mean it.
Nowadays I just sit here, contemplating where to send my CV making sure this sh.t which happened in Berlin with me never ever happens again, and teaching kids how the world just clicks together, by showing them how the universal design ideas (target groups, expressing purpose, use cases, problem-solution pairs, elegance, etc) are in [visual] design and [classical] architecture just as well as in software engineering; that is, I tell non-software guys how to do visual and text design for example.