Here are facts:<br>-No Agile/Scrum. Was described as "This is how EIS department works, with a variation of it.”. To later discover that the department and projects are not big enough for Agile. The other depts/rest of business are not Agile, they just started to hear about the word 'Agile', so we (our EIS dept/team) can’t be Agile;<br>
<br>
IOW: Project/Team work is prioritized via a two year old Redmine version with basic/minimal plugins to track tickets. You receive by email which ticket u must work on. Related documents, emails, notes, comments or links are spread out on file servers and wikis;<br>
<br>
-Ticket software: in-house hosted Redmine, 2yrs outdated, no plans to update/upgrade, server regularly slow and/or hangs, constrained to no plugins, static configurations and static customization. Many users export tickets to Excel to sort, prioritize, group, ... because its painful to do with current software;<br>
<br>
-No TDD/ATDD/BDD. Test server is a very slow and over 6yrs old, Jenkins is 2years outdated, last ran tests was over 18months, unit tests (only) – are self contained mocks only, no integration tests (to database), no UI tests, no test/sample database, no integration with VCS, nor CI/CD… Stopped doing TDD/ATDD because highly inefficient, to much code maintenance.;<br>
<br>
SunarQube evaluated TDD code coverage at: 5%;<br>
<br>
IOW: Before pushing to production, softwares are manually tested in your local development environment with IIS express!<br>
<br>
-No Staging, No Beta or nor Preprod version before moving onto Production environment;<br>
<br>
-No Deployment/Setup Scripts. A start of PowerShell Script exists for one project only;<br>
<br>
-No CI/CD. All done manually, on last minute decision;<br>
<br>
-No Tracking/Ticket + VCS integration: Developers create a branch per ticket to then manually copy-paste commit, branch and merge request links to ticket itself;<br>
<br>
-No (barely) branching & merge conflict strategy. Skeptical and annoyed by best practices. Master/Ticket Model is used: One ticket, one new branch off master, one merge request, repeat for each/next ticket. You wait days/weeks for your merge request to be accepted. Most often rejected because « ticket issue was not solved in a more generic/different way » - while it was not a requirement at first place;<br>
<br>
IOW: Branches are long lived, master branch is rarely updated, and when it is, multiple branches are out of sync and outdated with master, and lots of unresolved merge conflicts. When merge occurs, a review of branches, tickets and re-test worked on weeks ago!<br>
<br>
-Driessen’s “Git-Flow Model” with its built-in extensions was skeptically viewed, slow to understand+accept and wanted to change it’s (proven) process, thus limit use of existing built-in extensions. Best practice to Pull more often to get active branches updated with latest changes is rarely applied;<br>
<br>
-No established basic UI layout pattern: Long discussions/meetings as to where to place « OK », « Cancel », « Save », « Edit », « Delete » in dialog windows!;<br>
<br>
-Weak-bad UI design: Weak UI for a serious project involving lots of data entry and used thru-out 3 major clients, with inconsistent button layout, missing title bars, exaggerated spacing, etc. was accepted/implemented as is, and software deployed. Heavily used by to 2 clients, UI is currently being reviewed! Thus, UI and coding work done over again! Users will have to re-adapt to new UI;<br>
<br>
-Poor 3NF database: Duplicates and unlinked (orphans) data, absence of index on searched fields, absence of relationships between PK and FK, no data integrity option, no enforced multiple fields unique index, GUID fields in every table when other fields are set as primary key, …<br>
<br>
-DB first approach! Code first approach is not trusted;<br>
<br>
-Expect to read 20pages on how to and how not to manually format code files... when VS/VC/Resharper have shareable settings and do way better & faster & consistently & precisely! And then again, formatting document creates a “major/big” concern. A web side-by-side gitlab tool for code review is used, so just “a space, comma, new line, …” gives a “head-ache” to review code;<br>
<br>
-IOW: Expect to work in permanently unformatted code/files, methods with over 200-400 lines long, weak design patterns, old fashioned naming convention, inconsistent naming from DB to DAL to BL to UI, outdated code from master;<br>
<br>
-No error logging: Highly deficient Error/Exception management and logging. Barely used try-catch in API end points. If there is a try-catch, then catch have hard coded text « An internal error... » written to Console or Debug with no defined listener to log to file/db and with NO exception details. Implemented catch all error logging and json serializer exception handling with log4net in one project - the number of hidden errors now being logged revealed the level of maturity of coding!<br>
<br>
-Resharper: Approval for use & licences was long, and seen as skeptical, even though Solution Analyzer was listing over 5 200 errors+warnings in only 1 single software;<br>
<br>
-Naming convention is old fashioned: Don’t care and not interested in renaming, as it causes merge conflicts;<br>
<br>
-UI/User messages contain internal GUID instead of relevant « user friendly/useful » data information;<br>
<br>
-Expect a good load of sarcasm and passive-aggressive communication;<br>
<br>
-New candidates are not co-selected. And neither does candidate meet other EIS team members with whom he/she will eventually work with;<br>
<br>
Blind marriage!
