Първата ми работа като софтуерен разработчик, както е за мнозина, беше като стажант. Това беше B2B магазин за софтуер за трансформация на данни, който все още поддържаше стари IBM мейнфрейми и също така предлагаше по-нова версия на Java Enterprise Edition на платформата със софтуерни екипи, поддържащи и двете. Като стажант докладвах за „Директора на специални проекти“, човек, който направи точно това, което звучи: всичко, което трябваше да се направи, което не попадаше точно в компетенциите на други отдели. Той беше добър шеф и винаги намираше интересни проекти, с които да се занимавам, но по-важното за тази история беше магьосник на Visual Basic. Продажбите се нуждаеха от персонализирана система за отчитане? VB може да направи това. HR се нуждаеше от вътрешен инструмент за проследяване и категоризиране на часовете на изпълнителите? VB може да направи това. Професионалните услуги имаха нужда от нов оценител на разходите? да VB. Докато това привлече безкрайни, но добродушни оребрения от инженерния екип, неговите малки VB проекти запълниха празнините бързо и свършиха достатъчно добра работа, за да поддържат работата на компанията с ниска цена. Докато Amazon пуска новата си платформа Honey Code, виждам много извиване на ръце от общността на разработчиците, но трябва да приветстваме този инструмент. Точно както направи VB, той дава възможност на корпоративните потребители да създават бързи решения на много специфични проблеми и поддържа инженерните екипи фокусирани върху доставката на продукти.
Има нотка на елитарност, която се появява, когато се появят нови инструменти като Honey Code, и аз съм критикувал такива платформи в миналото. Често виждаме нови инструменти като този, насочени към нетехнически основатели като инструмент за бързо извеждане на техния MVP и без този обременяващ разход на инженерни таланти. Те пропускат да споменат, че цялата тази работа ще бъде загубена, когато в крайна сметка трябва да наемете някои инженери, за да кодирате v2. Тези инструменти рядко предлагат коректно персонализиране и кодови добавки, които позволяват разширяемостта да прехвърлят това, което може да предостави основната услуга. (И кой би се заел с изграждането на това разширение, когато няма инженери!?) Тези инструменти са твърде ограничени и неподходящи, за да бъдат сериозно значими като инструмент за изграждане на MVP на стартираща компания.
Но Amazon възприе различен подход с Honey Code. Те не предлагат змийско масло на основателите тук; това е нещо, с което Amazon трябва да се занимава. Вместо това Amazon го позиционира като ключов инструмент за критични процеси, които иначе биха се върнали към ненадеждни електронни таблици. Това ми показа старият ми директор на специалните проекти със своето VB майсторство. Това не са продукти, които се доставят до клиенти; техните „достатъчно добри“ интерфейси вършат работата.
Защо просто не разполагате с екип от разработчици, който да се заеме с тези проблеми? Няма ли това да направи полученото приложение по-управляемо и мащабируемо? Може би. Някои корпоративни проблеми са изключително критични в момента, но не съществуват достатъчно дълго, за да рационализират екипа на разработчиците, който отделя време за създаване на платформа. Ето защо решението често е просто проста електронна таблица; върши работата бързо. Посвещаването на ценно и оскъдно време за разработчици на нещо просто няма смисъл, но това, което има смисъл, е обучението на няколко технически разбиращи се членове на екипа на Honey Code. Решава проблеми. Спестява време.
Първоначално публикувано на https://johnjonesfour.com.
